饿了么技术往事（中）

在上一篇文章《饿了么技术往事（上）》中，我介绍了饿了么最早期 All in One 阶段的架构，以及第二阶段业务系统拆分与团队运营的一些思考，以及我对于架构师职责的感受，接下来我会详细介绍饿了么全面服务化的架构演进历程。

一、中间件

业务线的工程师深陷到快速的迭代和业务复杂性当中，业务的快速增长、外卖行业午晚高峰业务特点带来的并发挑战，领域拆分后所需的服务体系框架支撑，责任自然落到了中间件团队。

当时中间件团队主要负责的三件事就是发布系统、SOA框架、统一的数据访问层。

1. 发布系统

外卖业务周末的单量通常比工作日要高，但是工作日事故率要高于周末，为什么？变更是万恶之源，周末很少发布。所以，发布系统接手管控，取消手动发布的模式，解决发布回滚的问题，通过发布自动化提高效率的同时，回收服务器的权限，降低安全和稳定性的隐患。当然发布系统的作用远不止于此，后续这个体系及其团队充当起了基础架构演进的核心角色。这个是后话了。

2. SOA 框架

SOA框架是支撑业务服务的骨架。和多数类似框架一样，为应对复杂的服务体系，服务注册和发现，常见的基于Design for failure的设计，熔断、限流、舱壁、多集群隔离这些功能都一样。但是，较特殊的地方在于——我们有两套SOA框架，Java 版和 Python 版。前面提到，我们有两个主要的技术栈 —— Java 和 Python，使得我们凡是需要 SDK 的地方，都需要支持两种语言，毫无疑问会对增加中间件团队负担。在当时确实是个难题，这个现在当然也有解，后面会提到。

体会和教训——是否应该统一技术栈？

关于是否应该统一技术栈，没有一个标准的答案。每个公司的技术栈和技术体系，有其形成的背景，如同架构一样，不放在上下文里面讨论合理性，往往没有结果，烟囱型也好、L型也好，只要是适合自己的技术和架构就好。

Python 技术栈当时已经支撑了很多核心系统，推翻现有系统，换技术栈的时间成本不可忽视。而当时市场竞争非常激烈，对于饿了么这样的创业公司，数据、时间和人是最宝贵的。而且，有一支能力非常强的 Python 技术团队，从里面抽调部分工程师，支撑 Python 技术栈的中间件建设，也不会带来额外的人力成本。维护两个技术栈，中间件团队的负担会增加，但是，换取的是时间和优秀的工程师，还是划算。这些 Python 工程师里面，负责业务系统的很多人后来也成长为独挡一面的角色，跟上了业务快速增长的步伐（后续会有相关的内容分享）。而负责中间件的 Python 工程师，他们的一些创造性实践，也为我们后续架构演进奠定了基础。

好的技术体系和架构，起决定性的不是技术栈，最终还是优秀的工程师。

3. 数据访问层

因为多技术栈的存在，DAL 层选择了中心化的方案，而没有采取 SDK 。统一的数据访问层为后续分库分表、限流保护、多数据中心上线后的数据纠偏打下了基础。为了保证系统有足够强的吞吐能力，DAL 层采取了异步 IO 的方案来处理出入流量，中间件的最高境界是大家会忘记它的存在，DAL 层涉及到底层和数据库的交互，尤为敏感，而这个中间件几乎做到了，没有出现过重大事故，也很少有开发吐槽这一层的问题。后来，这个一直稳健的团队在饿了么多数据中心建设当中，负责了核心的流量调度及容灾切换管控体系。大家都习惯了叫 DAL，很多人不知道这个系统叫 Athena。

基于 DAL 的上线，DBA 和 DA 这个时期就忙着给各个团队做分库分表的事情：

按业务功能领域切分——拆库
按照访问频率、动静态属性等等规则——垂直分表

基于Hash Partition（需要注意的是避免热点和Rebalance带来的成本）—— 水平Sharding

总之就是选择合适的 Partition 策略，降低数据库单个实例的负载。存储后来能支撑住千万级单量，除了上游队列的削峰、缓存的缓冲、数据库读写分离以外，也得益于适当的 Data Partition 策略。

二、大前端

其他团队还在拼命追赶业务、填坑补课的时候，大前端团队满足业务需求的同时，还为开源社区贡献出了非常优秀的产品 Element。就在大家认为这支团队会继续在前端领域上一骑绝尘下去的时候，令人没有想到的是，这个团队几年后会爆发出巨大的潜力，成为整个架构体系升级中一个举足轻重的角色。为什么叫大前端&#x