外卖混合式架构
![仿美团饿了么APP同城外卖系统开发方案(第五章)插图 仿美团饿了么APP同城外卖系统开发方案(第五章)插图](https://www.huaqihao.com/wp-content/uploads/2022/11/同城外卖系统架构-300x175.png)
上图是外卖App引入MRN后的架构全景图,接下来我们会从下到上、从左到右逐步介绍:
*下层是Android/iOS系统服务层,因为MRN是跨端的,所以需要引入这一层。相对单一平台来说,由于MRN的引入,整个App的架构不可避免地需要考虑Android和iOS平台本身的差异性。
倒数第二层是平台服务层,这一层相对与单一平台来说,并没有太大区别。
再往上一层是MRN基建层,这一层的工作主要是:(1)尽可能地屏蔽Android和iOS系统的差异性;(2)打通已有的平台基建能力,让上层业务不能感知到差异。
再上一层是业务组件层,这一层相对于单一平台来说,区别不大,主要是增加了Android和iOS的RN容器,同时业务组件是可以被RN调用的。
继续往上是MRN接口层,该层的主要任务是尽可能地屏蔽Android和iOS组件之间的差异,让上层页面使用的RN接口保持一致。
是业务层,这一层是用户可直接接触到的页面,页面的实现可以是Android/iOS/RN。
左上角是研发支撑,主要包括代码规范、代码检查工具、Debug插件、准入规范、准入检查工具、代码模板插件等。这块相对于单一平台来说,主要的差异体现在:由于编译器和语言不同,使用的工具有所区别,但工具要做的事情基本是一致的。
左下角是测试支撑,主要包括UI自动化测试、自测覆盖率检查、AppMock工具、业务自测小助手、性能测试、云测平台等。这块相对于单一平台来说,基本也是一致的,主要的差异同研发支撑,主要是语言不同,使用的工具有所区别。
右上角是发布支撑,主要包括打包Bundle和APK、打包检查、发布检查、发布Bundle和APK等。这块相对于单一平台来说,保持了打包发布平台的一致性,区别在于:需在原有的基础上,增加MRN的打包发布环节。
右下角是运维支撑,主要包括基建成功率监控、业务成功率监控、线上问题追踪、网络降级等。这块相对于单一平台来说,保持了一致性,区别在于:需在原有的基础上,增加MRN的监控运维。
研发测试支撑外卖业务MRN组件架构
RN对双端只提供了30多个常用组件,与成熟的Native开发相比,天壤之别。所以我们在开发的过程中面临的一个很重要问题就是组件的缺失。于是,MRN团队基于RN组件进行了丰富,引入了一些优秀的开源组件,但是源于外卖业务的特殊性,一方面需要业务定制,另一方面部分组件依然缺失。所以为了减少重复代码,提升外卖客户端MRN的研发效率,建设外卖组件库就变得非常有必要。
![仿美团饿了么APP同城外卖系统开发方案(第五章)插图1 仿美团饿了么APP同城外卖系统开发方案(第五章)插图1](https://www.huaqihao.com/wp-content/uploads/2022/11/外卖系统架构路由-300x290.png)
上图是我们外卖组件库的架构图,层依赖Android和iOS的原生服务;然后是MRN基建层,用于抹平Android和iOS系统之间的差异;再上一层则是外卖组件库及其依赖,如平台组件库和打包服务,组件库分为两类:纯JS组件和包含JS和Native的复合组件。再上一层则是Android和iOS的MRN容器,它提供了上层Bundle的运行环境。整个组件的架构思路,是利用中间层来屏蔽平台的差异,尽可能地使用JS组件,减少对原生组件的依赖。这样可以有效地减少上层业务开发时对平台的理解。