饿了么：日订单量超900万的架构设计及演进之路
21CTO社区导读：
饿了么网站诞生在2009年，是由当时还在同济大学在读的学生张旭豪和同学一起的外卖生意衍生的平台。
跟很多人一样，这一帮学生并不喜欢自己的本专业，与其在毫无成就的的实验室闷着，还不如打游戏玩的爽。这几位开始琢磨着怎么创业，试了两个项目后，最后锁定了做外卖生意。
最开始是电话接单，接下来做配送，再和餐馆提成，这样也慢慢做了起来。后来接单多了忙不过来，对账又麻烦又容易出错。张旭豪决定，做网站！
没有什么合适的.com域名，想了一个饿了的名字，注册ele.me的域名，公司也起了名字：拉扎斯，听着就挺扎人。后来他解释说，这个词是希腊语『激情』的意思。
缺乏资金，靠给三轮车印海报推广网站，慢慢积累有了一些名气。张为了和餐馆搞好客户关系，经常和这些老板来往，甚至一起泡澡，以保证独家。
2011到2015年，饿了么获得多家VC机构投资，包括腾讯，阿里的资金与流量供给。它的外卖订单每天从几十万，到上百万。从2015开始，订单从330万左右，2016到500万，2017初超过900万单。
21CTO市场同学与张旭豪
从此饿了么APP具备了入口优势。本文是21CTO综合该公司的架构师来讲在千万流量下APP和网站如何应对外卖电商订单的并发处理，希望大家有价值。
概述
移动互联网时代演进，技术也随之发展。时至今天，APP已然成为绝大多数互联网企业用来获取用户的核心渠道。与此同时，伴随着业务量的增长，愈来愈大、愈来愈多的APP也在不断地、持续地挑战着每一个前后端研发人员的知识深度，技术人员也在这个不断接受挑战的过程中，成就了今天的移动互联网时代。
所有的技术人，在网站流量过大时都要面临这样一个挑战，多用户量、多业务量，在接受着更多更挑剔用户的同时，默默地、不断地演进着前后端的架构。
脱离业务谈架构就是纯粹耍流氓，每个平台后端架构的发展都是其业务发展的一面镜子。
饿了么网站在刚开始的时候大概只是一个想法：一个产业的模型，快速地将它产生出来。
“快”是第一位的，不需要花太多精力在架构设计上。
在网站进入扩张期才需要对架构投入更多的精力来承载网站在爆发时的流量。
饿了么网站到现在成立已8年，现在日订单量突破900万，亦具有了较完善的架构。
一、网站基础架构
从一开始，就使用了能够更容易拓展SOA的框架。SOA框架解决两件事情：
1. 分工协作
网站发展初期，程序员可能就1-5个，那时大家一起忙同一件事情就可以。彼此之间的工作都互相了解，往往是通过“吼”就能把问题解决。
随着人员的增加，这种方式显然是不行的，不可能一个人更新了代码再把其他人的所有代码重新上线一遍吧？于是开始考虑分工和协作的问题。
2. 快速扩展
以前订单量可能从1000到1万，虽然增长了10倍，但是总量并不是很高，对于一个网站的压力来说，也不是那么大。
真正的挑战是订单量从10万到100万，从100万到 200万的时候，数字上只是扩大了10倍，但对整个网站的架构上来说却是巨大的压力。
前面提到过，从2014年100万订单突破到现在的900万，技术团队由刚开始的30多人，到现在已经是超过900人的团队。
分工协作越来越成为挑战。服务的分分合合，团队的分分合合，这都需要一套框架体系来支撑，这也是SOA框架的一个作用。
下面是架构平台现状，中间为整个架构的体系，右侧是和服务化相关的一些基础，包括基础的组件或者服务：
先说开发语言，我们原来的网站是在PHP上开始的，后来开始慢慢转换。
创始人都是大学生创业，最开始想从Python开始做为首选。到现在 Python也是很好的选择，但是我们选择了Java和Go，这是为什么？
Python很多人都会写，但是真正能把它做得很好的人并不多。随着业务的发展，需要更多的开发人员。考虑到Java成熟的生态环境，以及新兴的Go生态，我们最终选择了Python、Java、Go多语言共存的一个技术生态。
其中：
WebAPI主要做一些HTTPS卸载、限流，还有安全校验等一些通用的和业务逻辑无关的操作。
Service Orchestrator是服务编排层，通过配置的方式实现内外网的协议转换、服务的聚合裁剪。
架构图右边是一些围绕这些服务化框架的辅助系统，比如说用于定期执行一个任务的Job系统。我们有将近快1000个服务，这些系统怎么监控？所以必须有一套监控系统。刚开始只有30多个人时，我们更擅长的是跑到机器上去搜一下Log，但到了900多人时，你不可能都到机器上去搜一遍Log，需要有个集中式的日志系统。其它的系统这里就不一一赘述了。
罗马不是一天建成的，基础架构是个演进的过程。
二、服务拆分
当网站变大了，原来的架构跟不上发展的节奏了。我们要做的第一件事是：
把大Repo拆成一个小Repo，把大服务拆成小服务，把我们的集中基础服务，拆分到不同的物理机器上去。
光是服务拆分用了一年多的时间才做完，这是比较漫长的过程。
这个过程中，首先要对API做一个很好的定义。因为一旦你的API上线之后，再做一些修改的成本是相当大的。会有很多人依赖于你的API，很多时候你也并不知道有谁依赖于你的API，这是一个很大的问题。
然后再把一些基础服务抽象出来。很多原来的服务其实是耦合在原来的业务代码里面的。比如说支付业务，业务很单一时，紧耦合的代码没有关系，但是扩展出的越来越多的业务都需要支付服务时，你每一个业务（比如说支付的功能）都要去做一个吗？所以我们要把这些基础服务抽离出来，比如支付服务、短信服务、推送服务等。
拆服务看似很简单、没什么价值，但这恰恰是我们刚开始就要做的事情。其实在这个时期，前面所有的那些架构都可以往后拖，因为不做架构调整其实不会死人，但是拆服务你不做的话，真的会死人。
服务拆分必定是一个漫长的过程，可这实际是一个很痛苦的过程，也需要很多配套系统的系统工程。
三、发布系统
发布是最大的不稳定因素。很多公司对发布的时间窗口有严格的限定，比如：
每周只有两天可以发布；
周末是绝对不可以发布的；
业务的高峰期绝对不允许发布；
我们发现，发布的最大问题在于发布上去之后没有简单可执行的回退（Rollback）操作。回退操作到底是谁来执行，是发布人员就可以执行，还是需要专人来执行？如果是发布人员的话，发布人员并非24小时在线工作，出了问题找不到人怎么办？如果是有专人来执行回退，而又没有简单、统一的回退操作，那这个人需要熟悉发布人员的代码，这基本上不可行。
所以我们就需要有发布系统，发布系统定义了统一的回退操作，所有服务必须遵循发布系统的定义回退操作。
在饿了么对接发布系统是对所有人的强制要求，所有的系统必须全部接入发布系统。发布系统的框架很重要，这个东西其实对于公司是很重要的一件事情，需要放到第一优先级的队列里面去考虑。
四、服务框架
紧接着就是饿了么的服务框架，把一个大的Repo拆分成一个小的Repo，把一个大的服务拆成一个小的服务，让我们的服务尽量独立出去，这需要一套分布式服务框架来支撑。
分布式服务框架包含：服务注册、发现、负载均衡、路由、流控、熔断、降级等功能，这里就不一一展开了。
前面已经提及，饿了么是多语言的生态，有 Python的，也有Java的，我们的服务化框架对应也是多语言的。
这对我们后来一些中间件的选型是有影响的，比如说DAL层。
五、DAL数据访问层
当业务量越来越大的时候，数据库会变成一个瓶颈。
前期可以通过提升硬件的方式来提升数据库的性能。如：
- 升级到一个有更多CPU的机器；
- 把硬盘改成 SSD 的或更高级一点的产品。
但硬件提升终归是有一个容量限制的。而且很多做业务的小伙伴，写代码的时候都直接操作数据库，发生过很多次服务一上线数据库就被打爆的情形。数据库被打爆掉了之后，除非等待数据库恢复，没有任何其它机会可以恢复业务。
如果数据库里面数据是正常的，业务其实都可以补偿出来。所以我们做DAL服务层的时候，第一件事情是限流，其它的东西可以放一放。然后做连接复用，我们Python框架用的多进程单线程加协程的模型。
多进程之间其实是不可以共享一个连接的。比如：一台机器上部署了10个 Python进程，每个进程10个数据库连接。再扩展到10台机器上，就有1000个数据库连接。对数据库来说，连接是一个很昂贵的东西，我们DAL层要做一个连接复用。
这个连接复用讲的不是服务本身的连接复用，而是说DAL层上的连接复用，就是服务有1000个连接到DAL层，经过连接复用后对数据库可能只是保持着十几个连接。一旦发现某个数据库请求是一个事务的话，那么DAL就帮你保留这个连接的对应关系。当这个事务结束之后，就把数据库的连接，放回到共用池里面去，供其他人使用。
然后做冒烟和熔断处理。数据库也可以熔断的，当数据库发生冒烟时，我们会杀掉一些数据库的请求，保证数据库不至于崩溃。
六、服务治理
服务框架之后，开始涉及服务治理的问题。服务治理其实是一个很大的概念，首先是做埋点，你要埋很多的监控点。
比如有一个请求，请求成功了或者失败，请求的响应时间是多少，把所有的监控指标放到监控系统上面去。
我们有一个很大的监控屏幕，上面有很多的监控指标。有专门的技术小组24小时去盯着这个屏幕，如果有任何曲线波动了，就找人去解决。
另外还设置了报警系统，监控屏幕展示的东西总归有限的，只能放那些很重要的关键指标。这个时候就需要有报警系统。
罗马不是一天建成的，基础架构更是一个演进的过程。我们的资源和时间总是有限的，作为架构师和 CTO 来说，如何在这种有限的资源下，产出更重要的东西？
我们做了很多系统，觉得自己做得很不错了。但实则不然，我感觉我们又回到了石器时代，因为问题越来越多，需求也越来越多，总感觉你的系统里还缺点什么东西，想做的功能也一大堆。
比如对于流程控制系统，现在我们还是需要用户去配一个并发数，那么这个并发数，是不是根本不需要用户去配？是不是可以基于我们服务本身的一个状态自动去控制并发数？
然后是升级方式，SDK升级是个很痛苦的事情。比如说我们服务框架2.0发布的时候是去年12月份，到现在还有人用1.0。是不是可以做到SDK的无损感升级，我们自己来控制升级的时间和节奏。
还有，我们现在的监控系统只支持同一个服务上的汇聚，是不分集群、不分机器的，那是不是以后的指标可以分集群、分机器？
举一个最简单的例子，比如一个服务上有10台机器，那么可能只是某一个机器上出了问题，但它所有的指标都会平均分摊到其它的9台机器上去。你只是看到了整个服务延时增加了，但有可能只是某一台机器拖慢了整个服务集群。我们现在还做不到更多维度的监控。
还有智能化的报警，这个报警，就是要快、全、准，我们现在做到更快了，做到更全了。
如何才能做到更准？每天的报警量高峰时间一分钟一千多个报警发出去。所有的一千报警都是有用的吗？报警多了之后，就相当于没报警——大家都疲劳了，就不去看了。
我怎么能够把这个报警更准确地区分出来？还有更智能化的链路分析？以后是不是我们的监控不要放监控指标，而是放链路分析，这样就能够很清晰地知道，这个问题对应的是哪一个结点上出了问题。
这些问题涉及技术团队做事的一个原则：东西够用就好，但是要能够未雨绸缪，做一定的超前规划。
小结
我们都知道，对于软件工程来说，这世界上没有银弹。对于架构而言其实也非常的适用。业务的不断更新，带来了饿了么移动APP架构的不断演进。
软件架构没有真正的好坏之分，只要适用于自己的业务，就是好的架构。你的看法呢？
作者：兰建刚（饿了么架构师）
本文为 @ 21CTO 创作并授权 21CTO 发布，未经许可，请勿转载。
内容授权事宜请您联系 webmaster@21cto.com或关注 21CTO 公众号。
该文观点仅代表作者本人，21CTO 平台仅提供信息存储空间服务。
评论
