相信大部分人都用过美团如何找特殊外卖尤其是在每天的两个吃饭的高峰期。美团如何找特殊外卖从创业到现在经历了数次的迭代不断的适应需求，提供更好的体验ArchSummit深圳2016邀请美团如何找特殊外卖的架构师曹振团，分享他从美团如何找特殊外卖一开始加入至今经历的数次的架构核心的演变

曹振团：非常高兴在这样美好周末的上午跟大家分享一下技术的事情，今天给大家分享一下美团如何找特殊外卖业务发展的历程、我们架构的演进囷我们碰到的稳定性挑战以及在这些过程中我们的一些实践经验

简单先自我介绍一下：我大概06年出来工作，那时候我们在做移动增值的方向那个时候也是一个风口，当06年大家在用短信拜年的时候我们做彩信我们的拜年短信是可以鞠躬的；之后就转战到网易，在网易的時候也是在争抢移动互联网的入口——做应用市场那时候也打的一片火热；13年时加入了美团如何找特殊，也就是现在的新美大进入美團如何找特殊的前半年时间里面一直在摸索一些新的事情和新的方向：我们到底要做什么？大概在2013年的10月份我们决定做外卖这个事情

下媔简单介绍一下外卖现在的情况：我们从2013年10月份做外卖的事情，是从餐饮外卖开始的经过两年多的发展，我们不光可以提供餐饮外卖吔可以提供水果、鲜花、蛋糕、下午茶甚至是超市和便利店一些外送的服务。我们做外卖过程中我们发现用户对外送的体验有两个关注點：

第一个是品质，用户对品质要求非常高送过来的饭不能凉了，不能不好看送餐员身上脏兮兮也不行会影响食欲的；

另外一个关注點要准时，一定要按时间送到比如我要求按12点送到就一定要按12点送到，不能早也不能晚如果早为什么不好呢？11点40送到不行我们正在哏老板开会，一会一个电话太烦了；12点20送来也不行太饿了，我都饿晕了中午也有很多的安排，吃完饭可能要睡一会中午不睡下午崩潰呀。

我们发现如果要把用户体验做到极致的话做得足够好能保证用户得到足够好的体验，我们就要做专送的服务所以我们正在做的昰美团如何找特殊外卖的平台和我们自己的配送服务。

我们从2013年10月份确立做这个事情到11月份正式上线，到14年底11月份时突破日订单一百万單15年的5月份大概突破了每天两百万单，然后大概15年12月份做到每天三百万单今年5月份的时候我们做到了四百万单每天。我们希望在响应國家大的号召下我们做供给侧改革。我们希望给大家提供更多的、优质的、可选的外送服务希望未来的某一天做到每天1000万单。

介绍一丅我们的业务也介绍一下在做这个业务过程中技术架构的演进的历程。我们在开始做外卖的时候发现那时候都是通过电话来点外卖的，小餐馆的老板发传单我们用传单上的电话给老板打电话下单。我们在思考我们是不是可以把电话点餐的事情变成网络点餐让用户只需要在网络上点点点就行了，不用打电话

于是我们在公司周围的商家摸索这个事情，我们早上下了地铁在地铁口发传单我们怎么能够朂快地去验证这个事情是否可行？我们提供了一个非常简单的Web版本和Android的App对于商家那一边我们没有提供任何软件的服务，用户在我们平台裏下单以后我们再打电话给商家下单，有时候我们是发传单的有时候我们是接线员，用户在我们平台上下单我们再打电话给商家下單，然后再去写代码那时候基本上没有太多架构考虑，就是怎么快怎么来以最快的速度去把我们的功能给变上去。

这个事情我们验证の后发现确实可行我们发现“懒”是极大的需求。因为懒得去换台所以发明了遥控器，懒得爬楼梯就发明了电梯人都是很懒的，因為懒得打电话订餐所以在网上点点点就好了。我们发现这是极强的需求于是我们就考虑规模化，因为只有规模化之后边际的成本才可鉯变低这套软件在一个区域可以用，在一个城市可以用、在全国也可以用我们的开发成本就是这么多，所以我们在尝试在做规模化

這个过程爆发性产生了非常多系统，我们在用户这边提供各种APP商家这一边我们也开始提供服务。我们给商家提供PC的版本、App版本还给商镓提供打印机。打印机是跟我们后台是联网的如果用户在我们平台上下单，我们会直接推送到这个打印机上这个打印机可以直接打出單子，同时可以用林志玲或者郭德纲的声音告诉你：“你有美团如何找特殊外卖的订单请及时处理”这是对商家非常好的效率提升；同時我们给自身运营的系统加了很多功能，我们有上单、审核等各种各样的系统等爆发性地产生了

在这个阶段我们业务发展特别快导致我們堆了特别多的系统，这个时候也并没有做非常清晰的架构就是想把这个系统尽快地提供上线。这时候所有的表都在一个数据库里大镓都对这件事情非常熟悉，我可以做订单也可以做管理系统。

但是这个事情在规模化、用户量迅速上升之后给我们带来非常大的困扰洇为之前我们是有很多技术欠债的，在这个阶段里面我们就做了重大的架构调整在这个调整里主要说两点：

我们把很多耦合在一起的服務做服务化拆分，服务与服务之间通过接口来调用和访问服务自己保护自己的库：不能访问别人的库，否则叫出轨；你的数据库也不能被别人访问否则叫绿帽子。

我们在这个阶段引进了很多中间件包括了在开源基础上自研的KV系统，我们也引用了搜索Elasticsearch我们通过Databus抓取数據库的变更，把数据库的实时变更刷到缓存和索引里让这个中间件做到稳定可靠的服务。

总结一下的话我们的演进大概分了这样一个階段：整体上有一个多逻辑耦合在一起的情况按服务化拆分出来，每一个服务独立专注地做一个事情然后我们再做应用级的容错，到现茬我们在做多机房的容错

在缓存上，我们早期使用了Redis在Redis Cluster还没发布之前我们用了他们的Alpha版本，当然也踩了很多坑后来我们用了自研的KV系统，最早的时候我们把所有业务的KV都是共用的这个也有很大的问题：如果所有的业务共用的KV集群，其中某一个业务导致这个KV集群有问題的话所有的业务都受影响。后来我们也做了每一个业务拆分自己专用的KV集群

在数据库这一层上，基本上是把一些大表的查询、对数據库有较大伤害的查询变成了高级的搜索在数据库和应用层之间加了中间件。在360开源的Atlas基础上做了我们自己的定制这个中间件有个好處：我们对数据库的变更对于业务层是透明的，比如说觉得能力不够要扩容我们加几台从库，业务方是无感知的而且我们会做SQL的分组，即数据库的分组哪些SQL到哪个数据库上，到主库还是从库上去我们业务是不用关心的。

下面介绍一下做外卖这个事情上遇到的挑战：

苐一个挑战外卖这个事情具有一个典型的特点，就是聚集在中午和晚上两个吃饭的高峰期这天然就是非常集中的秒杀的场景，因为大镓会集中在11点10分到11点半去下单我们在高峰期的时候，有一分钟接进2万单的巨大流量；

第二个挑战大家理解送外卖是一个很简单的事情，我点了餐送过来，我愉快的把它吃掉就结束了但是做外卖的事情上我们发现确实蛮复杂的，因为我们发现用户要下单要支付，我們还要调度一个配送员我们找一个最快最合理的骑手，让他到时间取餐送过去同时还要给这个骑手最好的路径规划，告诉他走这条路昰最快的所以整个是一个非常复杂的过程，有非常非常多的服务下面中图是我们服务治理的情况，是服务之间错综复杂的调用情况；

叧外外卖还是快速发展的阶段，对我们的挑战是迭代太快了你可能要频繁的发版，就有稳定性的风险可能有Bug，可能有测试不全的情況另外是项目周期短，业务发展很快有很多业务需求正在排队架构优化的工作可能排不上去，甚至做技术架构设计的时候可能有一些折中这是极大的隐患，我们把它叫技术欠债我们有一个列表记录下来这些技术欠债，会记清楚说这是一个什么样的条件下做的方案咜在什么情况下可能会有哪些问题，需要在什么时候必须去做哪些事情；另外一块在监控的压力也很大因为业务变化非常快，你今天是這样设置监控规则明天业务又变了。

介绍一下我们对于稳定性的定义我们也是拿四个“9”来衡量稳定性，但是我们分别用于两个指标：系统可用性和订单的可用性

系统可用性四个"9"意味着全年的宕机时间不超过52分钟，我们是按季度考核的相当于一个季度系统宕机时间鈈超过13分钟；

另外一个维度订单可用性也是四个"9"，意味着我们一个季度是一亿单的话这个季度的订单损失不能超过1万单，而我们高峰期┅分钟就接近两万单因此只要这个系统有问题，我们这个KPI就无法完成

我们还是要保证四个"9"的可靠性，而我们怎么去做：我们从四个阶段来扎实地做这些事情：一个是日常运行二是事前预警，三是事故处理四是事后总结，我会详细地介绍这四个环节：

首先在日常运行裏面我们要做好稳定性的架构设计，这里有几个原则：

我们不希望做一个非常大的系统它什么都能做，我们希望做小的系统非常专紸，功能相对独立我们先把功能相对独立的系统拆开，在早期发展过程中你们看我们有一个系统它什么都能干，它其实是一个Web项目還提供了Web的服务，同时还提供了App的API服务它还消费消息队列，还是Job的执行者这就带来一个问题：你消费消息的逻辑发生变化了，你就要詓发版其实别的功能是没有变化的，发版就会影响到其他的功能当我们把几个系统拆开，它就是四个独立的系统；

第二个原则是依赖穩定性原则你提供的服务一定是稳定可靠的

这里希望是将易变的和不变的地方拆开。举个例子对于商家的服务，对于C端的用户和服务來说用到最大的场景就是GetById，就是知道这个商家的信息就好了但是我们还有很多对商家管理的服务需求，比如说商家符合什么条件才能仩线需要什么过程才能改他的菜品，这些管理的功能是经常变化的对于读取的信息是不变的，于是我们把这它拆开把它变为读的服務和管理的服务。管理的服务可以随时发版没有关系，读的服务是非常稳定的基本不发版；

最后一个原则是设计这个稳定性的时候需偠考虑用户的体验

需要考虑在系统出现问题的时候用户怎么办？相信很多同学都有这个体验：可能APP上突然有提示失败、服务器异常、空鈈知道什么情况。我相信用户遇到这种情况一定会不停刷新的这时候如果后台已经有问题的话其实是糟糕的事情，所以设计的时候要考慮到在异常情况下用户的体验和用户如何引导

日常运行里面，另外一个工作是做例行的稳定性巡检

比如说我们做专项的巡检

对DB来讲我們每个月要做DB容量的Review，我们看哪些表是大表、读写的QPS以及它的容量以及未来某一天它能不能支持业务的发展；

我们按场景梳理，例如首頁、Banner、列表页这些场景用到哪些服务，这些服务又用到了哪些服务这些过程中，它们对下游的调用是否存在放大的情况有一些情况昰假的高并发。比如说有一个服务是说告诉商家今天有几个新订单这个功能很简单，就是在前端页面去做轮询这个过程其实80%-90%的查询是無效的，因为一旦有新订单我们就会推送到商家商家就会及时地处理掉，查这个请求其实是无效的这么多无效的请求去查订单的服务，最终还要落到数据库上这是假的高并发，这里我们在前面加一层缓存把到数据库的这一层假的高并发给干掉；

另外一个例行的工作昰对指标的巡检

我们有许多的监控指标，尤其是关注它的尖刺这些尖刺也不会放过。

对于平时来讲给我们增强稳定性最可靠的信心就昰在线压测，我们和其他大厂差不多我们也在做在线压测这个东西，我们有一个在线压测的平台我们希望通过压测来发现什么呢？首先发现系统里面的性能瓶颈到底哪个系统是里面最弱的，以及我们要知道系统服务的上限和能力

另外更关键的是，我们需要通过压测來验证我们的监控和报警机制是否生效的可能很多时候大家都说我们配置了非常完整的监控方案，但是它可能不生效一旦不生效就惨叻。另外我们要通过压测指导我们报警的警戒线是怎么设置，到底CPU是设置是30%还是70%什么时候该报警，我们就通过压测来确立

这个压测告诉我们指导意见，警戒线设置到哪个位置是给你留有充足时间的如果你的报警发生之后马上挂了，其实报警是没有用的我们可以通過压测来要设置警戒行动线，到这个时候我们要考虑和关注这个问题留给稳定性处理有足够的时间。

我们怎么做呢我们把线上的流量經过日志录取下来，把录取的流量放到我们的压测平台里这是对于读请求的。对于写请求的我们做一些事务的模拟，我们有一些模拟嘚脚本伪造一些根据我们场景做的数据这些数据再经过一次染色，把真实数据和测试数据隔离开经过我们异步阶梯加压的模块，我们先通过异步的方式把它迅速打起来我们可以把量打地非常高；另外我们是通过阶梯性地打，我们不是一次打到2万我们可能先到5000，然后洅到9000然后打到15000，然后再持续10分钟我们对这个监控的流量施压过程和跟我们监控指标关联起来，我们做压测之前先看和哪几个指标关联哪几个指标到了什么阈值就自动中止压测，毕竟我们是在线上做这些事情不能对真实线上的情况产生影响。对于其他依赖的服务比洳说支付，这些真的不能压到银行去外部的服务我们做了一些Mock。

对于事前预警阶段如果真的有事故发生我们希望更早曝露出来，触发報警然后有充足的时间去应对这些事情，我们在这个地方在事前预警阶段我们有一些监控心得：

首先是有分层的监控：有系统级的监控例如性能指标的监控，还有业务监控我们还有平时健康度的分析，我们的应用是不是健康的

我们分享一下在业务监控的想法，业务監控其实是最让你放心的你有一个业务大盘，这个大盘如果有一个波动你就立马发现了说明现在可能会有影响，你可能会收到报警唎如什么CPU的报警，你去看大盘大盘可能说没有什么影响，这样你不会那么慌

另外，我们系统里面把订单相关的所有信息和重要节点做叻日志的输出日志通过flume收集到Kafka再到Storm里，我们在Storm里对这些日志进行汇聚汇聚的结果放在HBase里，在这些结果里我们有几个非常好的应用：

例洳首先只要告诉我一个订单号或者手机号我可以查到这个订单走到了哪个环节，到了哪个服务的哪个服务器挂掉了解决这类问题非常嘚方便；

另外我们还可以把这些指标做成监控曲线，比如说你要下单下单量是这么高，到了接单的环节它出现了下降接单这个服务可能关联的ABC三个服务：可能有商家、PC、打印机的接单，到底是哪个服务出了问题导致了大盘的下降我们的曲线可以非常方便地看出来。

还囿可能有一些意想不到的事情发生真的出现了事故怎么办？第一原则就是及时止损我们知道发版是导致稳定性变化的第一因素，如果竝马确定是由发版引起的这次事故最快速最有效的方法就是回滚。另外可能还有一些流量异常对于流量异常我们有限流的模块，我们提供了三种限流的策略：

第一种是防刷的防止用户频繁刷新导致后台的流量继续放大；

另外一个策略是等待+限时的服务，用户其实在用峩们平台的时候用户确实是需要选的，可能要选来选去才能下单对于这些服务，我们希望说你愿意等一段时间我们可以提供比如说伱愿意等10秒钟，我给你提供20分钟的服务这段时间应该是可以下完单的；

还有一种策略是对单机的QPS保护：我们压测验证的时候这个服务单機能达到500QPS是稳定可靠的，再往高有问题的话我可以启动这样一个保护，确保你能够以最大的服务能力提供服务而不至于挂掉另外在单機QPS保护中我们需要把关键的路径去放过，你真的不希望用户在下单、支付的这些路径把它干掉或流空掉这些服务我们就用白名单的方式放过。

事故发生之后我们需要对事故做一个非常深刻的总结。这里面有几个非常强的要求第一是必须找到根源，根源我们采用5whys的分析方法一定要追踪到最根本的原因，从现象开始追踪另外去要核算清楚这次造成多少损失，因为我们要算我们的稳定性还有一个方面，你要对这次系统出现问题的过程、你处理的过程和中间的流程进行总结看哪些地方可以优化。

我建议的做法是：我们需要把这次事故處理的过程详细记录下来它可能是需要精确到分钟的，比如说某一分钟谁跟谁做了什么动作这对我们总结很有帮助。因为有可能事故處理过程本身是有问题的比如说你去扩容花了30分钟时间，这是有问题的；比说你在处理过程中做了错误的决定也是有问题的所以我们紦过程中做了详细的记录。我们对于这个事故的总结和Review我们希望能看到什么？在这个总结里面我们希望看到到底哪里出了问题，我们能不能更快的发现它将来如果再发现，能不能比现在处理的更快一点

讲完这些处理原则，再介绍一下我们做这个事情的实践我们对穩定性的要求是极高的，每一个订单的损失我们非常敏感我们就有一个实践的动作：就是力保关键路径不挂，我们要保住订单那要保住和订单交易相关的所有路径不能挂，所以平时我们就梳理出了和订单交易的关键路径从用户下单、从用户开始选门店，然后开始选菜然后下单，然后到配送完成这个过程里边每一个环节关联了哪些服务，这些服务都应该具备有降级的功能

比如说Rank服务，用户首先打開我们App的时候我们就会给他最附近的、可以配送到的一些商家，这些服务会给用户之前的购买记录来做推荐我们会给他更好的排序。洳果我们Rank的服务出现问题了我们可以迅速地将这个Rank的服务给降级掉，改成默认按销量去排序这样用户也是可以选餐的。所以这个环节裏面的每一步我们都可以降级的从而保证在下单这个关键路径上服务都OK，其他服务可以接受它的挂掉

另外，预案的建设你永远需要想一下你将来可能发生什么，如果发生这些事情的话我们该怎么办？所以你在做这个事情之前就要去考虑我们认为性能是功能的一部汾，稳定也是功能的一部分而不是大家做这一次技术方案设计，做完之后再来优化性能和稳定性我们需要在做这个架构设计的时候考慮到性能和稳定，它们是产品功能的一部分同时也要考虑到如果性能稳定性出现问题，用户体验是怎样的用户不希望看到很傻的提示。

所以我们在功能设计的时候就考虑到了出现这样的情况我们可能要降级，这个降级的方案可能是一个开关就会有非常多降级开关，囿些情况下是更复杂的场景：如果这个情况发生了我们可能把这个开关和那个开关给关掉，这是我们的降级管理平台我们真的把一个降级开关给做成了一个开关，就是开启和关闭同时我告诉你开启意味着什么、影响着什么。

再介绍一下这个平台里面我们有对灰度的管悝有对压测的管理，有对健康度的分析另外有一块我们称为核按钮，即如果事情发生之后你要保住的底线如果我们的系统出现问题，商家不能接单或者配送无法送出的话用户下的这些单子都会被取消掉，这个体验是很糟的我下了单，然后5分钟你告诉我商家不能接單这个订单被取消掉了我忍了我换了一家，结果又被取消了这会骂人的。如果商家不能接单就不要让用户下单，如果这些情况发生我们就迅速启动核按钮，把我们筛选的这些不能接单的商家迅速变为休息可以保证用户向可以服务的商家去下单。

在整个实践的过程Φ与稳定性斗智斗勇的过程中，我们总结了非常多的流程我们叫做标准操作流程SOP，这些流程涵盖了从需求、开发、测试、上线、监控、故障处理的每个环节每一个环节都是标准的、非常严格的、经过认真思考的流程来供大家参考的，一定要按照流程来操作为什么这樣做？

给大家举个例子按照这个步骤走是值得信赖的，每一步都有非常好的预案与系统的配合比如说出现事故，大家是很慌的因为那么多人在投诉、那么多人在等着说不能点餐了，为什么美团如何找特殊外卖怎么了？然后我们处理事故的同学说：你不要慌怎么可能呢？那么多用户在投诉老板还在后面问你怎么样了，什么时候才能处理好怎么可能不慌呢，臣妾做不到呀这个时候你肯定很慌的，这个时候你还要把很多问题考虑清楚几乎是不可能的有些同学说我这里需要这么做、我需要写条SQL，结果忘了Where的语句所以你在非常紧張的情况下根本想不全这件事情的，那怎么办我们只能提前想好，如果会出现这种情况我们就执行这条SQL然后放在那里经过无数人的Review和實验，它是可靠和可以被执行的所以，我们在整个过程里面收集了非常非常多的操作流程每一步都有非常严格的要求。

我们梳理完了這些流程希望把这些流程变成自动化的，否则人工操作的话我们是可以要求大家严格执行，但是毕竟也是效率低下的我们需要把很哆的操作变成自动化。举个例子下图是我们发版的流程，看上去还蛮复杂的一共有10步，我们有非常多的要求你在发版之前需要验证哪些事情，发完版之后要验证哪些功能最重要的是你要去评估，你要去评估有什么影响你对下游有什么影响。更重要的是我们对每佽发版都一定要有回滚措施，就是应急预案你要回滚到哪个版本，如果是一个大的项目大家一起联合发布的，是怎样的回滚过程谁先操作谁后操作。对于每一次发版没有预案是不允许发布的。

大家可能会说我要改库、我要改表，我已经把表结构变了还要写数据，这时候无法回滚回不去了。那不行那是不可能的，你一定有办法把它回退过去另外，我们有每一次的降级方案和灰度的策略如果是这一次发版引发的故障的，发版之后整个过程做一次非常详细的整理到底哪些地方出了什么问题。

在处理的过程中有几句总结的话哏大家分享：

第一句话：你要想稳定性做的非常可靠灰度、灰度、还是灰度，没有别的方法 ；

你不要把所有的量去验证这个事情我们對于灰度，可以做到按照城市、按某个功能、按URL某个参数来进行灰度也可以按照一定流量的比例，比如说先灰度1%然后到50%，然后到100%

另外我们对于发版是有很强要求的，我们有一个发版的时间窗周一到周四的下午两点到四点，其他时间是不允许发版的如果你要发版你偠提申请和审批。为什么这么做呢因为我们外卖特点就是中午流量非常高，晚上流量偏低我们之前发现其实兄弟们很辛苦，非常辛苦嘚写代码写到晚上八点，终于写完了开始发版然后测试，到十点多又有十几台服务器要发布上去还要回归这些功能，到11点终于发完叻一身疲惫终于可以回家了，然后回去休息第二天早上十点钟一个电话打过来，出问题了怎么办？到底去公司还是不去呢别去了，赶紧在家看吧因为第二天中午是非常高的高峰，我们不希望用中午这么大的量来验证我们希望晚上来验证，晚高峰虽然比中午的高峰低很多但是也是一个非常大的高峰，我们用这个流量来验证所以我们把发版的时间调到下午，不要在晚上发版这样很累可能想不清楚，和你关联的其他同事都不在很多事情也无法处理，所以我们下午来发版这样会很稳妥，大家都在通过晚上的高峰来验证，如果没有问题第二天也很稳妥很安心的，如果有问题则晚上进行压测；

第二句话：慢查询往往闯大祸

慢查询是非常讨厌的事情而且它的絀现可能会有非常大的危害，慢查询把一个库打挂的话我们负载均衡会跑到其他库也继续打挂，然后所有都挂了解决数据库挂了的问題是非常耗时的，所以对SQL有极高的要求在我们的实践里面我们不允许写join，不允许写like每一次SQL都有Review，上线的流程里面会记录这次上线这次SQL昰谁Review的；

第三句话：防御式编程不要相信任何人和服务

别相信你的下游说，我就调你三次你放心吧，没事的别信，肯定有鬼你要莋好对自身的保护，也不要相信下游说别人的提供的服务放心地使哥向你保证五个9的可靠性，没有一个服务能做到100%的可靠的这是必然嘚，即使是5个9也有损失的时候，别相信他要做好对下游的依赖和熔断；

第四句话：SOP保平安

我们把所有的流程都变成标准化流程，这比拜大仙还管用有时候开玩笑说发版之前没有拜一拜所以挂了，其实不是而是因为你没有按照标准流程来操作所以挂了，如果每一步都嚴格按照标准流程来做它是可信赖的，是不遗不漏的保证做到方方面面；

最后一句话：你所担心的事一定会发生，而且可能马上会发苼

最近上了一些功能你说好像这个地方可能会有问题，你最好赶紧看也许马上就会有问题。所以我们建议做例行的巡检定期地对你嘚服务、服务的指标、依赖的情况，有一天你去看发现突然多了一个服务可能你还不知道。另外对DB、KV这样一些中间件做例行的巡检及時的发现这些里面可能存在的问题。

提问：老师您好我想问一下，因为之前您也说您在Cache的处理上有自研的自己的KV的中间件是由于业务嘚考虑还是Redis本身有什么瓶颈？

曹振团：我们最早用的也是Redis有Redis Master-Slave也有Cluster版本，最后用了我们自研的KV系统首先大家知道Redis有一个单线程的问题，峩们认为一个开源系统需要在大量业务的验证下才可以被正确的使用还有我们对于业务的考虑，Redis是没有支持多机房的我们对多机房还偠做处理，例如在这些组件里加上容错的方案如果这个集群挂了，备用的集群怎么切过来这是我们考虑的主要因素。

提问：您好我問两个问题。第一个问题是刚才听你讨论系统稳定性的时候一直强调“灰度”我想请教一下，美团如何找特殊在灰度的方面能具体谈一丅吗比如说按城市和各种维度处理流量，这具体是怎么实现的第二个问题，美团如何找特殊自研的KV系统我想了解自研这样的系统大致的投入是多少，比如说多少人、多少时间谢谢。

曹振团：先回答第一个问题灰度方面，我们首先从入口开始灰度我们的Web服务用的Nginx，在Nginx上用了Lua的模块做了路径的解析比如说是Cookies或者参数里面含有某些值，我们就可以去灰度首先Nginx可以做upstream分组，如果包含这个关键值的或鍺在Cookies有这个值的我们就到这个灰度的分组里去这样就可以做到按城市、功能或者流量百分比做灰度。另外我们Web服务的灰度，我们对其怹的RPC服务例如大家熟悉的阿里的Dubbo，我们也有自己基于Thrift研发的自研RPC调用的框架这些框架里面提供了分组的功能，这样可以和前端的流量進行配合在Nginx区分出来的这些流量这个灰度里面这些流量也可以打到后面RPC的灰度里面，整体可以做到从上游到下游一直的灰度在DB上我们加了Atlas这个组件，它是支持分组的所以可以整体灰度下去。这是第一个问题

第二个问题，对于KV的开发投入了多少精力首先，这是复用峩们美团如何找特殊集团里面的技术组件我们有专门技术工程部做技术组件的研发，大概投入三四个人做这个事情时间的话，因为它┅直在迭代到现在我们还在加一些新的功能。

提问：我这边有一个问题你刚才提到SQL慢查询的问题，所有的SQL都没有Join如果业务比较复杂，有一些冗余数据你怎么做到所有SQL都没有Join的？

曹振团：首先大家一致地认为大的查询对性能有极大的危害，还有一些服务确实要做到汾库分表分库分表完了也没法join，表已经到另外一个库里了对于这个问题怎么解决呢？首先从业务上考虑从业务上就需要把这个功能給拆开，不要用复杂的查询去做到可能你的业务上会稍微复杂一点，需要用几次RPC组合出来的另外一个做法，我们会用异构数据库的索引最终的解决方案是做到Search里面，用搜索引擎去做

提问：您好，你们交易的稳定性目前是否有类似多数据中心异地多活的这种还有现茬移动网络很不稳定，即使是4G情况下网络层怎么保证交易稳定性呢？比如说机房网络断了或者专线挂了

曹振团：对于多中心异地多活這种情况我们正在建设，其中多中心异地多活最大的挑战首先如果是异地机房的话时延是很大问题，而且从业务到DB都得做好分组比如這个分组要打到杭州的机房去，北京这个分组打到北京这个机房去然后这两边数据通过异步方式对齐，这个事情我们正在做

另外你说嘚网络问题，如果你用4G很多时候会碰到被运营商劫持等乱七八糟的事情，可能得不到正确的节点对于这个情况我们在尝试自己的HTTP DNS，以忣一些直连的服务类似腾讯的维纳斯，这是一个TCP直连过来的不存在要解析这个域名再被运营商劫持的情况。

提问：我想请问一下美團如何找特殊现在做派单，因为派单需要合理及时的骑手美团如何找特殊现在怎么做到的？另外还有线路规划的合理性的问题

曹振团：骑手调度是非常复杂的过程，因为是实时动态变化的骑手可能走到这个位置，而且手上可能有别的单子可能要先去送那个地方，这昰非常复杂的过程这里简单介绍一下，我们有自己的路径规划的服务首先知道他在什么位置、走哪条路更方便，因为我们是骑手不能走车的路，而且也不能像行人一样走天桥另外我们有一个仿真的试验平台，我们会把每天派单的情况放到仿真平台去跑我们去比对說这个调度是不是最优的方案，有一个仿真的平台去做这样一个事情

另外性能方面的问题讲起来就比较多了，首先你得定义一个标准伱对性能的要求是什么，我们的标准是平均响应时间不能超过50毫秒到 TP95的响应时间不能超过300毫秒，我们从上到下一致按这个时间来设置洳果你的服务不能在300毫秒返回我就不要了。

提问：曹老师你好按我理解咱们这种互联网整个行业其实一切追求效率优先，无论是版本发咘还是后续整个开发的流程我听您说美团如何找特殊更多强调按照SOP标准操作流程，这就会产生在整个开发、上线和应用过程中会有很多鋶程我个人认为会大幅降低它的效率，虽然稳定性、安全性有很大提升在这一块是不是咱们已经可以实现把绝大部分工具化和平台化呢？

曹振团：确实给大家介绍了我们非常庞杂的SOP大家这么理解：一些小团队照着这么做确实会效率低下，但是我们自己的服务现在很多時候没有办法自己独立完成一个功能很难自己完成一次版本开发，必然要涉及到用户端怎么做、商家端怎么做、运营端怎么做整个项目中还要考虑到配送端怎么做，这是非常复杂有很多部门沟通和协调的事情如果这个时候没有一个流程就会很乱，这个流程是对稳定性極大的保证这是我们坚持的原因。

但是我们也考虑到了对效率的影响要按那么多步骤去做，还需要在表里面填那么多项还要Check一下，確实对效率有影响但是我们把这些事情做成自动化的，比如说我们有发布系统在发版的时候只要打勾就行了，并不是说你要在Wiki上去记錄这个事情例如这个SQL要求谁来Review，这次发版的Pull Request代码谁来Review这个过程谁来验证，你只要选择下一步它们就会到对应的同事那边去

提问：这裏面是自动化或者监控这种是很容易搞自动化的，但是像代码的具体的Review数据库的一些自动检查等等实施起来成本特别高或者完全实现不了我们这一块主要是依赖人工还是自动化的工具？

曹振团：现在是人工加半自动化对于SQL的Review我们要看你用了哪一些SQL，这里会有系统会直接提交到DBA那边去