饿了么技术往事（中）

本文插图
在上一篇文章《饿了么技术往事（上）》中，我介绍了饿了么最早期 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 这个时期就忙着给各个团队做分库分表的事情：