外卖平台架构总结 第1篇

好的架构源于不停地衍变而非设计。美团外卖的架构，历史上也是经历了很多次迭代。由于外卖业务形态不断地发生变化，原有的设计也需要不断地跟随业务形态进行演进。在不断探索和实践过程中，我们经历了若干个大的架构变迁。从考虑如何高效地复用代码支持外卖App，逐渐地衍变成如何去解决多端代码复用问题，再从多端的代码复用到支持其他频道业务的平台架构上。在平台化架构建设完成后，我们又开始尝试利用动态化技术去支持业务快速上线的诉求。如今，我们面临着多端复用、平台能力、平台支撑、单页面多业务团队、业务动态诉求强等多个业务场景问题。下文我们针对美团外卖移动端架构的变迁史，做一些简单的概述，以便读者阅读本文时能有更好的延续性。

外卖平台架构总结 第2篇

从搜索库拆分的第一次尝试算起，外卖Android客户端在架构上的持续探索和实践已经经历了2年多的时间。起初为了解决两端代码复用的问题，我们尝试过自上而下的强行拆分和复用，但很快就暴露出层次混乱、边界模糊带来的问题，并且认识到如果不能提供两端差异化的解决方案，代码复用是很难持续的。后来我们又尝试过运用设计模式约束边界，先实现解耦再进行复用，但在推广落地过程中认识到复杂的设计很难快速推进下去。

在平台化开始的时候，团队已经形成了设计简单、边界清晰的架构理念。我们将整体结构划分为宿主层、业务层、平台层，并严格约束层次间的依赖关系。在业务模块拆分的过程中，我们借鉴微信的工程结构方案，按照三级工程结构划分业务边界，实现灵活的代码隔离，并降低了后续模块迁出和迁入成本，使得架构动态满足康威定律。

在两端代码复用的问题上，我们认识到要实现可持续的代码复用，必须自下向上的逐步统一两端底层的基础依赖，同时又能容易的支持两端上层业务的差异化处理。使用Flavor管理两端的差异代码，尽量减少向上依赖，在具体实施时应用之前积累的解耦设计的经验，从而满足了架构的可伸缩性。

没有一个方案能获得每个人的赞同。在平台化的实施过程中，团队成员多次对方案选型发生过针锋相对的讨论。这时我们会抛开技术方案，回到问题本身，去重新审视业务的痛点，列出要解决的问题，再回过头来看哪一个方案能够解决问题。虽然我们并不常常这么做，但某些时刻也会强制决策和实施，遇到问题再复盘和调整。

任何一种设计理念都有其适用场景。我们在不断关注业内一些优秀的架构和设计理念，以及公司内部美团App、点评App团队的平台化实践经验，学习和借鉴了许多优秀的设计思想，但也由于盲目滥用踩过不少坑。我们认识到架构的选择正如其他技术问题一样，应该是面向问题的，而不是面向技术本身。架构的演进必须在理论和实践中交替前行，脱离了其中一个谈论架构，都将是个悲剧。

外卖平台架构总结 第3篇

虽然我们具随时备动态发布能力，但正常的版本迭代还是会存在中，所以外卖这边的节奏是周动态迭代+双周版本迭代，这保证了我们的开发工作有个一清晰的周期。在动态发布阶段中最关键的阶段操作上线阶段。以MRN为例，目前外卖业务中应有70多个bundle，再算上测试环境的bundle就有接近150个bundle，只是管理这些bundle就是一个复杂的工作，况且在进行上线操作时还是涉及发布的目标App、App版本的上下界、MRN版本的上下界等，一不小心就会造成操作失误，所以进行上线操作时需要非常谨慎。

我们针对操作上线阶段进行了事务流水线，通过流水线建立保护措施，一个bundle的上线要经历一个流水线的若干操作。首先，操作人根据上线SOP手册进行若干检查操作，同时编写标准格式的发布说明，然后周知相关核心人员后在操作系统上发起上线申请，Leader和QA收到申请后会进行检查并审批，审批通过后还要避开App使用的高峰期或节假日上线，上线后通过灰度发布观察各项数据指标，指标正常后全量发布。