共计 3781 个字符，预计需要花费 10 分钟才能阅读完成。
| 导读 | 一个产业的模型，快速地将它产生出来。“快”是第一位的，不需要花太多精力在架构设计上。在网站进入扩张期才需要对架构投入更多的精力来承载网站在爆发时的流量。饿了么成立已经 8 年，现在日订单量突破 900 万，我们也有了较为完善的网站架构。 |
初期，我们使用了能够更容易拓展 SOA 的框架。我们用 SOA 的框架解决两件事情：
网站初期，程序员可能就 1~5 个，那时大家忙同一个事情就可以了。彼此之间的工作都互相了解，往往是通过“吼”的方式就把问题解决了。
但随着人员的增加，这种方式显然是不行的，不可能一个人更新了代码再把其他人的所有代码重新上线一遍吧？于是就要考虑分工协作的问题。
以前订单量可能从 1k 到 1w，虽然增长了 10 倍，但是总量并不是很高，对于一个网站的压力来说，也不是那么大。真正到了订单量从 10w 到 100w，从 100w 到 200w 的时候，可能数字上只是扩大了 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，这是一个很大的问题。
然后再把一些基础服务抽象出来。很多原来的服务其实是耦合在原来的业务代码里面的。比如说支付业务，业务很单一时，紧耦合的代码没有关系，但是扩展出的越来越多的业务都需要支付服务时，你每一个业务（比如说支付的功能）都要去做一个吗？所以我们要把这些基础服务抽离出来，比如支付服务、短信服务、推送服务等。
拆服务看似很简单、没什么价值，但这恰恰是我们刚开始就要做的事情。其实在这个时期，前面所有的那些架构都可以往后拖，因为不做架构调整其实不会死人，但是拆服务你不做的话，真的会死人。
服务拆分必定是一个漫长的过程，可这实际是一个很痛苦的过程，也需要很多配套系统的系统工程。
发布是最大的不稳定因素。很多公司对发布的时间窗口有严格的限定，比如说：
- 每周只有两天可以发布；
- 周末是绝对不可以发布的；
- 业务的高峰期绝对不允许发布；
- 等等……
我们发现，发布的最大问题在于发布上去之后没有简单可执行的回退操作。回退操作到底是谁来执行，是发布人员就可以执行，还是需要专人来执行？如果是发布人员的话，发布人员并非 24 小时在线工作，出了问题找不到人怎么办？如果是有专人来执行回退，而又没有简单、统一的回退操作，那这个人需要熟悉发布人员的代码，这基本上不可行。
所以我们就需要有发布系统，发布系统定义了统一的回退操作，所有服务必须遵循发布系统的定义回退操作。
在饿了么对接发布系统是对所有人的强制要求，所有的系统必须全部接入发布系统。发布系统的框架很重要，这个东西其实对于公司是很重要的一件事情，需要放到第一优先级的队列里面去考虑。
紧接着就是饿了么的服务框架，把一个大的 Repo 拆分成一个小的 Repo，把一个大的服务拆成一个小的服务，让我们的服务尽量独立出去，这需要一套分布式服务框架来支撑。
分布式服务框架包含的服务注册、发现、负载均衡、路由、流控、熔断、降级等功能，这里就不一一展开了。前面已经提及，饿了么是多语言的生态，有 Python 的，也有 Java 的，我们的服务化框架对应也是多语言的。这对我们后来一些中间件的选型是有影响的，比如说 DAL 层。
当业务量越来越大的时候，数据库会变成一个瓶颈。
前期可以通过提升硬件的方式来提升数据库的性能。比如：
- 升级到一个有更多 CPU 的机器；
- 把硬盘改成 SSD 的或者更高级一点的。
但硬件提升终归是有一个容量限制的。而且很多做业务的小伙伴，写代码的时候都直接操作数据库，发生过很多次服务一上线数据库就被打爆的情形。数据库被打爆掉了之后，除非等待数据库恢复，没有任何其它机会可以恢复业务。
如果数据库里面数据是正常的，业务其实都可以补偿出来。所以我们做 DAL 服务层的时候，第一件事情是限流，其它的东西可以放一放。然后做连接复用，我们 Python 框架用的多进程单线程加协程的模型。
多进程之间其实是不可以共享一个连接的。比如：一台机器上部署了 10 个 Python 进程，每个进程 10 个数据库连接。再扩展到 10 台机器上，就有 1000 个数据库连接。对数据库来说，连接是一个很昂贵的东西，我们 DAL 层要做一个连接复用。
这个连接复用讲的不是服务本身的连接复用，而是说 DAL 层上的连接复用，就是服务有 1000 个连接到 DAL 层，经过连接复用后对数据库可能只是保持着十几个连接。一旦发现某个数据库请求是一个事务的话，那么 DAL 就帮你保留这个连接的对应关系。当这个事务结束之后，就把数据库的连接，放回到共用池里面去，供其他人使用。
然后做冒烟和熔断。数据库也可以熔断的。当数据库发生冒烟时，我们会杀掉一些数据库的请求，保证数据库不至于崩溃。
服务框架之后，涉及服务治理的问题。服务治理其实是一个很大的概念。首先是埋点，你要埋很多的监控点。
比如有一个请求，请求成功了或者失败了，请求的响应时间是多少，把所有的监控指标放到监控系统上面去。我们有一个很大的监控屏幕，上面有很多的监控指标。有专门小组 72 小时去盯着这个屏幕，如果有任何曲线波动了，就找人去解决。另外是报警系统，一个监控屏幕展示的东西总是有限的，只能放那些很重要的关键指标。这个时候就需要有报警系统。
罗马不是一天建成的，基础架构更是一个演进的过程。我们的资源和时间总是有限的，作为架构师和 CTO 来说，如何在这种有限的资源下，产出更重要的东西？
我们做了很多系统，觉得自己做得很不错了，但实则不是，我感觉我们又回到了石器时代，因为问题越来越多，需求也越来越多，总感觉你的系统里还缺点什么东西，想做的功能也一大堆。
比如对于流控系统，现在我们还是需要用户去配一个并发数，那么这个并发数，是不是根本不需要用户去配？是不是可以基于我们服务本身的一个状态自动去控制并发数？
然后是升级方式，SDK 升级是个很痛苦的事情。比如说我们服务框架 2.0 发布的时候是去年 12 月份，到现在还有人用的是 1.0。是不是可以做到 SDK 的无损感升级，我们自己来控制升级的时间和节奏。
还有，我们现在的监控只支持同一个服务上的汇聚，是不分集群、不分机器的，那是不是以后的指标可以分集群、分机器？举一个最简单的例子，比如一个服务上有 10 台机器，那么可能只是某一个机器上出了问题，但它所有的指标都会平均分摊到其它的 9 台机器上去。你只是看到了整个服务延时增加了，但有可能只是某一台机器拖慢了整个服务集群。但我们现在还做不到更多维度的监控。
还有智能化的报警，这个报警，就是要快、全、准，我们现在做到更快了，做到更全了，怎么才能做到更准？每天的报警量高峰时间一分钟一千多个报警发出去。所有的一千报警都是有用的吗？报警多了之后，就相当于没有报警。大家都疲劳了，就不去看了。我怎么能够把这个报警更准确地区分出来？还有更智能化的链路分析？以后是不是我们的监控不要放监控指标，而是放链路分析，这样就能够很清晰地知道，这个问题对应的是哪一个结点上出了问题。
这些问题涉及我们做事的一个原则：东西够用就好，但是要能够未雨绸缪，做一定的超前规划。
