美团点评伴随着业务的飞速发展，客户端研发团队的规模从初期的20余人的发展为数百人，且分散在不同的业务团队。如此大规模的研发团队，如何保证高效的内外部协同效率？ 美团与大众点评原本是两家独立运营的大型互联网公司，分别有着不同的积累和储备。两家的合并为业务带来巨大的好处：更多的流量、更多的用户。但同时也为技术团队带来了巨大的挑战：如何能够同时高效的在美团和大众点评两个App上实施业务开发？ 突破了这些难题之后，我们希望继续提高我们的研发效率。经过系统性的分析，我们判断测试效率当前阶段的效率瓶颈，对应的解决思路是实施自动化测试。那么问题又来了，类似美团点评的业务在不停的快速发展和迭代，是否适合实施大规模的自动化测试？

前言
　　伴随着业务的飞速发展，美团点评的客户端研发团队的规模从初期的20余人的发展为数百人，且分散在不同的业务团队。拥有如此大规模的研发团队，他们是如何保证高效的内外部协同效率？美团与大众点评原本是两家独立运营的大型互联网公司，分别有着不同的积累和储备。两家的合并为业务带来巨大的好处的同时也为技术团队带来了巨大的挑战——如何能够同时高效地在美团和大众点评两个App上实施业务开发？
　　在突破了这些难题之后，美团希望继续提高自身的研发效率，经过系统性地分析，他们的解决方案是实施自动化测试。那么他们是如何在大规模业务开发团队中高效实施自动化测试，进一步提升研发效率和质量的？
　　本文就带你揭晓美团点评技术团队背后的故事，分享一些美团点评客户端团队的技术架构及其设计思路，帮助团队技术负责人设计有利于提升研发效率的业务架构。以下全文来自美团技术研究员梁士兴在2017北京ArchSummit全球架构师峰会上的演讲。
　　1 为什么要建设客户端架构？
　　客户端架构与客户端或APP的发展经历是相关的。早些年APP通常是由个人开发者或者小团队来实施，那时候它往往是作为一个业务创新或某一个实践去做的。
APP从小型变成了巨无霸，代码动辄上百万行，美团移动支付的占比也早就超过90%，开发团队也从小变大，美团点评现已有数百人专门从事APP开发。迭代周期主要和业务的重要性相关，如果是核心的业务载体，迭代周期就需要做得越来越频繁、越来越迅速。
　　美团点评使客户端架构统一是希望得到这方面的收益，通过标准化，就可以实现三个统一：统一的基础设施、统一的逻辑分层、统一的开发范式。然后会带来四个明确的好处：
　　1.让一线开发人员聚焦在业务开发上；
　　2.可以实施灵活的人力调配；
　　3.可以用标准化的方式介入一个新的业务以支持其快速启动；，
　　4.一旦实现了标准化，必然可以基于它做一些自动化的实现，可以把一些相对机械重复的事通过自动化去取代人工。
　　最终带来的好处是：可以更好地服务业务。
　　2 美团客户端的演变历程
　　上图是针对美团客户端整理的技术研发体系。纵向是按时间和阶段划分的，横向按业务逻辑、开发范式、技术栈整理出来的。从技术体系图来看，进行业务开发的技术挑战其实是蛮大的，需要了解数据采集、监控、质量保证等方方面面。设计业务架构的目的是让业务研发人员把精力集中在业务开发上。
　　美团客户端架构发展分为三个阶段：
　　蛮荒阶段：这个阶段并没有什么体系化的架构设计；
　　标准化的阶段：内部细分了三个小阶段，实现了业务隔离、基础设施复用、开发范式等。
　　自动化是正在建设中的阶段，希望通过使用工程自动化的手段去持续提升效率。
　　3 蛮荒阶段
　　蛮荒阶段也就是最初的APP形态，众所周知，美团是做团购起家的，万物都是团购，在这个阶段美团并没有针对性地设计任何架构相关的东西。但是团购有一个好处就是可以以很低的成本把业务触达到各个领域，在这个阶段中，美团实现了业务遍地开花，很轻松地触达到不同的品类，比如酒店、电影等。于此同时，美团也让移动APP成为了核心业务载体，移动支付的占比超过了90%。
　　面临的挑战
　　那这个阶段能继续下去吗？挑战很快就接踵而至。挑战主要来源于两个方面：业务差异化和业务间的协同效率，从业务层面上来讲，虽然美团实现了业务的遍地开花，用团购方式触达到各个业务领域，但还不足以把业务做深。例如：团购这种形式并不适用于所有的领域，如酒店一定要预定，它和美食的团购行为是不一样的，这个时候要有诉求地去深耕业务，把不同业务特点的东西做出来，就是所谓的垂直化。因为业务这边已经有了不错的发展，换句话说就是赚到钱了，所以团队的规模在极速扩张，同时美团的研发团队被拆分到各个业务去，这也是为了更好地服务业务。
　　4 标准化阶段
　　针对第一阶段，美团主要通过分层和隔离的方式来解决问题，首先把跟各个业务都无关的和与各个业务都相关的公共基础设施定义为平台的基础设施。我们把一个平台做强，同时在这个平台的基础之上去构建各个业务，而且在业务里面进行有特色的垂直化建设，这个阶段会带来很明显的收益。
　　通过这样的平台设施，在一定程度上实现了复用和业务的积累，解决了业务之间的耦合，各个业务在物理上会隔离开，放到不同的代码仓库里面，只是在构建的时候把他们集成在一起，这种模式还有一个好处，就是为新业务的接入保持开放，任何一个新业务都可以按照规范轻松地接进来。
　　具体步骤
　　如果想要达成这样的目的，首先应该开发一套标准的业务模板，所有的新业务都按照这个模板去开发，根据模板的内容去进行业务的定制，并且通过统一的方法来实现接入，谁做比较合适？显然是新业务，让新业务去做小白鼠，在这个阶段里，短期内是可以接受代码拷贝的，通过解耦拷一份代码，将其分到一个独立的仓库里。为什么说短期可以接受这种行为？客户端有一个特点，哪怕不动弹，过一段时间页面也会被产品改得面目全非。
　　那么在这个过程中美团的收益是什么？总结起来有三点：
　　1.首先是在业务层面实现了业务间的隔离，解除了业务间的干扰，再也不会看到改电影模块导致酒店模块出现故障的现象，也不会把外卖的东西展示到美食区；
　　2.在工程层面上实现了工程标准化，使得新业务接入的方式是标准化的；
　　3.在技术层面上实现了独立的编译和二进制的集成，一旦实现了业务间的独立编译，就可以利用分布式的系统进行多机构建，这样就可以极大地缩短应用的构建时间。
　　但梁士兴认为这个阶段并不完美，还有很大的改进空间。因为一线开发者的研发效率并没有因为这次重构得到任何提高，这是为什么呢？因为开发层面没有标准化，代码复用是非常困难的一件事，所以需要实现开发范式，通过定制开发范式，将开发过程统一化，开发产物也是标准化的，可以被更好地复用起来。
　　统一开发范式
　　从上图来看，茴字有五种写法，而USB接口的实现方式更多。也就是说客户端开发的实现方式有很多种，这就使得复用变得非常困难，因为大家做事的方式都不一样，业务模块接口也是不统一的，想用统一的方式把所有模块调度起来就会非常困难。
　　这个问题让开发范式的目标明确了起来，开发范式实现的是书同文、车同轨，即开发方式统一化，业务接口标准化。
　　在这里以一个实际页面为例，这是一个复杂的页面，这个页面天然地划分成若干块，从这几个角度上来讲，页面本身并不存在什么东西，所有东西都被放到模块里，经过这样的抽象，我们把页面上的每一块定义为一个模块，同时页面会退化成模块容器的概念。
　　进一步来说，模块之间通常存在着通信的需要，这种通讯包括UI上的联动、数据的共享等，模块之间如果需要强依赖去获取数据，则模块之间也存在着依赖，这个是不能接受的，我们设计的目标是希望能实现模块级别的复用。
　　为此，梁士兴说他们团队引入了一个消息总线的概念，可以允许模块在上面订阅或发布消息，通过这种方式也能实现模块之间的耦合。他们还进一步对模块的内部也进行了约束，要求模块统一，按照这样的方式去组织，能够更好地实现自动化测试。经过这样的设计，美团主要页面的实现方式得到了统一，最直接的好处就是模块可以跨业务复用了。