转载

专访美团外卖曹振团：天下武功唯快不破

马云曾经说过：世界是懒人创造出来的。在“懒人”们的推动下，O2O的战火已经燃烧到了外卖行业。据报告，2015年外卖市场年交易额已经达到450余亿元，其中美团外卖从2013年底上线以来，已经迅速超过了400万日订单。作为美团内部的创业项目，美团外卖是如何一步步从复用美团的基础服务，到如今具有在高并发下百万级别订单的业务系统的。

2016年7月15-16日， ArchSummit全球架构师峰会将在深圳举行。本届大会，我们邀请了美团外卖技术专家曹振团老师，前来分享《美团外卖系统架构演进与系统稳定性经验谈》的内容，讲述在美团外卖业务的高速发展中，系统架构各阶段面临的不同挑战以及对应的解决方案。

现在我们就来采访曹振团老师，让老师给大家送一份充满干货的“外卖”。

InfoQ：在你认为，怎样的架构是一个好架构，怎样的架构师是一个好的架构师？能否谈谈如何避免一个“坏”架构的诞生？

曹振团：一个好的架构是与业务特点及与业务发展阶段相结合的、因地制宜且与时俱进的。一个好的架构既能支撑业务的快速稳定发展，又能留有一定的灵活性和扩展性。而好的架构师需要做好三点：

首先需要 充分理解业务 ，只有充分理解业务之后才能使架构不仅能够很好地支持业务特点，并具有一定的前瞻性。架构师需要站在推进业务发展的角度上合理地改进和优化架构设计，为业务的快速发展做好保障。
其次，架构师要 具备良好的沟通和协调能力 。架构师往往要面临着跨组、跨团队、跨事业部甚至跨事业群的一些技术方案，需要沟通和协调各方的诉求和冲突。
最后要具备 持续学习的能力 。不仅要学习技术知识的变化，更要学习业界的发展思路、最佳实践等。

好的架构是实践出来的，好的架构师也是在实践中快速成长起来的。新美大内部对架构师的培养非常注重实践和交流。架构师都在业务一线深入了解业务、需求及技术特性。美团外卖业务在快速发展的过程中踩了很多坑，这也让我们的架构师更快的成长起来。新美大内部各事业群的Casestudy都是共享的，这也是一个非常好的学习平台，从他人的经验和总结中学习。另外内部开设有架构专题分享，提供给大家一个架构实践的交流和讨论的平台。

架构通常是为了解决系统的高并发、高性能、高可用的问题，结合业务特点在研发资源、排期、技术方案之间做平衡。一个“坏”的架构则破坏了这种平衡，比如：由于工期紧张而引入了一个自己并不能把控的技术方案，为系统的稳定性埋下了雷。还有一个简单的判断标准是：当采用这个架构后在未来多长时间或几倍增量下需要调整架构。基本上要求至少在未来的半年到一年内或2倍增量下不需要调整架构。如果架构设计评审不符合这个标准就要及时重新设计或调整。

InfoQ：你曾在网易工作过，能否简单谈谈在架构设计上美团外卖与网易各自的特点是什么？

曹振团：门户网站面对着海量的新闻事件及分类，具有更新量大、过期快和热点集中的特点。新闻资料基本是静态的，所以对缓存技术应用较多。

美团外卖涉及到交易的信息、支付、履约的各个环节，参与方较多。从用户支付下单到商家接单，还有骑手配送等环节，这些过程都是动态有交互的，美团外卖对服务化及服务治理设计较多。

InfoQ：你加入美团后有参与多个创新业务的探索，那么你认为在业务初期好的架构是必要的吗，为什么呢？能否分享经历了多个创新业务之后的收获，这些经验给美团外卖带来了什么样的收获和挑战？

曹振团：2013年加入美团时，我们在O2O这个方向上进行了多个创新业务的探索，完全是新的事情，从零开始。在早期最重要的事情就是验证需求，验证产品是否能够满足用户的核心需求，是否能够被用户接受。这一阶段就是快速试错，通常以MVP的方式快速迭代。我们需要足够快地找到方向， 此时灵活性优先于架构。

加入新美大的早期参与公司内部的创业，在O2O这个领域进行了多个创新业务的探索，最后决定做外卖这个业务。在经历创新业务后最大的收获主要讲两点：

创业的早期决定不做什么往往比决定做什么更重要。在早期产品技术资源都很紧缺，需要将有限的资源投入到最核心的产品需求上。
天下武功唯快不破。如今的市场瞬息万变，唯有快速的迭代，方能抢占先机。

创业会给技术带来大量的挑战：首先需要是个全面手，前端、后台、数据库、运维都能够迅速切入。另外也要有足够的技术视野和深度，才能够在技术方案的选择上游刃有余，既能快速的选择合适的方案，又能够把握其技术原理。

InfoQ：美团外卖创建初期是否借鉴了美团的架构设计？美团外卖架构的创建和发展经历了什么样的过程？

曹振团：美团外卖创建初期复用了很多美团的基础服务，主要借鉴了团购业务积累的经验。美团外卖的架构是随着业务的发展优化和演进的。主要经历了以下几个过程：

自由发展阶段：业务起步的时候，大家公用服务和数据库表，这样能够快速支持产品迭代。产品和技术人员聚焦在快速验证产品功能上。到底应该有哪些功能，用户会如何点外卖等？这个阶段主要的特点就是集中，所有的功能都集中在几个项目里，所有的表都集中在一个库中。
故障驱动架构：随着业务的爆发增长，早期的架构出现了很多的问题，系统频繁地出现稳定性的问题，共享数据库表导致业务逻辑散落各地、甚至实现不一致的情况。这时系统稳定性问题倒逼架构进行优化调整，进行了服务化拆分，服务之间全部用接口的方式调用。
架构驱动改革：随着单量的快速增长，系统故障所造成的损失是巨大的、不可接受的。需要从架构驱动技术体系的改进、甚至推进产品和业务的变革。同时增加业务的容灾能力，进行了多机房的部署。

InfoQ：在外卖交易流程中，哪个环节最容易出现问题，你们是如何解决的？

曹振团：美团外卖在快速发展的过程中踩了很多坑。比如发版引发的故障，这类问题一般是最多的。发版的新功能可能含有bug，可能含有慢SQL，可能没有正确处理网络异常等。外卖业务还是一个实时且流程较长的业务，尤其流量比较集中在中午和晚上的饭点，在高峰时段的QPS是万级别的，外卖整个链条还会涉及到很多的服务，如果某个依赖服务有问题将会影响到其它服务。例如没有设置合理的RPC超时时间，如果服务A挂了，会导致依赖该服务的其它服务出现问题，进而引起连锁反应，最终系统雪崩。

针对这些问题，我们做了关键路径梳理。整个交易流程中梳理出关键路径，非关键调用异步化，关键路径做好容错容灾设计，实时监控关键路径的核心指标。整体系统做了比较全面的应急预案，当有紧急情况发生时，力保关键路径不出问题。

至于如何避免掉坑，分享几点：

防御式编程，不要相信任何人或服务，做好对自身服务的保护和对依赖服务的熔断。
每次发版都有预案。回滚是解决发版引发故障的最快捷有效的手段。
灰度！灰度！灰度！
完善的监控很重要，需要覆盖系统性能及业务指标，并对这些指标熟知和敏感。

InfoQ：在美团外卖业务急速发展的同时，目前美团外卖架构上是否有需要改进和突破的地方？是否有关注前沿的技术，目前通过什么渠道来发现持续优化架构的方法？

曹振团：业务屡创新高及团队规模的扩大，给技术架构带来了越来越多的挑战。如何能够在大规模作战的情况下，既能保持业务开发的敏捷性又能保障系统的稳定性，是我们架构中要重点思考的，我们一直在结合着业务发展的节奏，优化和改进技术架构。一方面要与时俱进地支持多品类的业务扩展及平台化建设；另一方面，在永恒不变的话题“稳定性”方面，在为能够支持更高的业务量，持续抽取和优化基础服务，加强中间件的能力，使各服务能够更聚焦和专注。因此加强基础设施和强固中间件的建设是我们要改进和突破的地方。夯实技术基础设施和中间件，让研发力量更聚焦在业务开发中。

美团外卖在技术架构中大量使用了开源的技术组件，在深入调研后会结合外卖的业务特点做二次开发，感谢Java社区里丰富的开源软件，使得我们能够更好地优化我们的架构。另外一个发现和持续优化架构的方法是全链路的在线压测。我们会定期进行全链路的在线压测，发现系统的瓶颈并优化验证。

InfoQ：在架构演进过程中分别使用了哪些核心指标来判断公司架构是否改善？你们对核心指标的要求是多少，目前是否已经稳定达到？

曹振团：架构的演进是为了能够提供更可靠的SLA，核心的考量指标有：5倍的容量，4个9的可用性，TP99 200ms的响应时间，目前已经可以稳定达到了。这些指标界定了系统能够在一定的容量下具有稳定和可靠的表现。我们会定期地做全链路的在线压测，通过实时的数据指标监控系统分析和验证是否已经达成架构目标。可用性和响应时间在服务端还是比较好衡量和达成的，但是从用户端看就变得复杂了很多。比如用户的设备、网络环境等都可能会对结果造成影响，我们也在加强用户侧的监控，持续地优化和改进用户体验。

InfoQ：外卖领域作为一种懒人经济，你们认为这些“懒人”在数据上体现了怎样的特征？

曹振团：有一种说法是“世界是由懒人驱动的”。由于懒得去换台，发明了遥控器。懒得爬楼梯，发明了电梯。如果你懒得出去吃，我们可以送外卖上门。懒是一个强需求。

我们在解决这个强需求的过程中，发现了一些有趣的变化：由于出现了这样的外卖平台，满足了大家懒的需求，越发使大家变“懒”了，平均点外卖的次数在变多，花样在变多（大家的口味在变多）。虽然变“懒”了，但是对品质的要求却在提高。我们通过优化配送链条上的服务，使得能够更及时、快速地为“懒人”提供美食。配送变快了，口感有了更好的保证。这又促使一些之前不提供外卖服务的品牌商家加入到外卖平台上来，使得整个生态更加良性发展。

另外一个特征是，“懒人”的需求也是多样的，“懒人”们希望能够提供更多的外送选择，这将会改写“外卖”的定义，它将会含有更广阔和丰富的含义，而不只是 “美食外卖”。

InfoQ：作为架构师，有什么感悟和经验和大家分享吗？

曹振团：主要分享几点吧：

性能是功能的一部分，稳定是功能的一部分 。性能和稳定性需要在开发设计的时候作为产品功能的一部分来考虑，而不是扩展属性。这样才能在开发、测试、上线、运行中全程把握。
简单即美 。把复杂的事情简单化，抓住核心脉络，解决好主要矛盾不见得一个大而全的海纳百川的架构才是好的，相反清晰、明了的架构是我们追求的，简单可依赖。
使用能够驾驭的技术 。丰富的开源社区给了我们很多的选择和视角，任何引入的开源技术都应该理解其原理和本质，只有能够驾驭的技术才能用好。
细节决定成败 。软件架构是一项复杂和精细的工作，只有把每个细节都做极致了，才能保障架构的基石稳健。