美团外卖前端容器化演进实践 _美团

提单页在美团外卖交易链路中非常重要，但随着业务不断发展，提单页模块越来越多，逻辑的耦合也越来越重。为了解决这一问题，需要实现提单页的动态化，而动态化是需要基于容器来实现，所以，美团外卖技术团队提出了提单页的容器化方案。希望本文对同样深受此问题困扰的同学有所帮助，有所启迪。

文章插图

背景
提单页的位置
提单页是美团外卖交易链路中非常关键的一个页面。外卖下单的所有入口，包括首页商家列表、订单列表页再来一单、二级频道页的今日推荐等，最终都会进入提单页，在确认各项信息之后，点击提交订单按钮，完成最终下单操作。

文章插图

文章插图

所支撑的业务
虽然提单页的代码统一放在外卖代码仓库中，但根据业务发展的需要，提单页上的模块分别由不同的业务部门去负责维护。主要包括以下业务方：
外卖侧业务

提单页绝大部分模块的需求开发和日常维护都是由外卖侧的研发同学在负责，包括地址模块、商家商品信息模块、折扣信息模块、准时宝、隐私号、发票备注等。

闪购侧业务

当从商超等频道进入提单页时，提单页生成的是闪购侧订单，闪购侧的订单在配送方式、红包、下单路径上都与外卖订单有所区别，但又依赖于外卖的基础功能模块，因此与外卖侧功能存在严重的耦合问题。

其他业务

提单页上的部分模块对动态化配置能力有着很高的要求，这些模块使用mach等动态化模版来实现相关的业务逻辑，由专门的业务组负责开发和维护。

文章插图

随着业务的不断迭代，提单页的模块也越来越多，逻辑的耦合也越来越重。现在提单页的UI展示模块已经超过30个，这些模块的展示与否基本上通过服务端的下发数据来决定。在不同的订单类型下，提单页所展示元素的差异越来越大，很多模块的代码已经不适合统一放在一起维护，代码拆分的需求十分强烈。此外，客户端包体积是衡量客户端性能的重要指标，为了解决业务发展带来的提单页代码量急剧增长的问题，同时实现页面元素的动态配置，我们希望能够实现提单页的动态化，而动态化需要基于容器来实现，所以我们提出了提单页的容器方案。
问题和挑战
提单页的容器化与外卖首页的动态化有以下几点不同：

提单页整体动态化的需求不是很强烈，并且API改造的成本比较高，因此API接口字段保持不变，需要在客户端层面去做转换。
首页模块基本仅作为展示用途，提单页模块的交互逻辑要复杂一些，比如发票模块，进入二级页面操作完成后还要更新提单页的数据。
首页模块的UI展示各模块之间是完全独立的，而提单页的模块是根据功能聚合在一个组，这些模块条件出现的位置不同，展示的样式也不一致，如下图备注发票模块所示，最上层和最底层的模块上都带有圆角，所以提单页需要外层再添加一个模块组。

文章插图

容器化后的提单页，需要实现模块之间的互相无感知，根据服务端的下发数据，客户端可以将闪购代码仓库内的模块和外卖代码仓库内的模块拼接起来组成完整的提单页展示给用户。当用户在提单页完成一系列操作时，各模块可以提供必要的参数给服务端。要想实现这一点，我们需要考虑以下几个问题：

模块注册问题，如何在无直接依赖的情况下，让提单页获取页面可用模块。
API数据分发问题，如何将服务端字段转换为模块可用数据，同时不侵入到模块这一层。
通信问题，模块之间如何实现联动效果。
页面更新和复用问题，在提单页刷新时如何提交数据给服务端以及如何完成模块的更新。

设计方案
1. 容器化整体的架构图设计

文章插图

容器化是我们在外卖平台化之后对多方业务能力的支持和扩展，在不改变API数据源等前提下，我们保证其具有动态可配置化的能力。为了更好地支撑业务，我们在业务层面抽离出来容器化框架层，其所提供三个部分的核心功能: 1.功能节点扩展及通信功能；2.可配置化功能；3.数据分发功能。在最上层业务容器中，目前所支持外卖提单页面模块、闪购提单页模块、提单页Mach（外卖动态化模板）模块、提单页MRN（RN页面）模块四种不同的业务。