饿了么技术往事（上）

作为一个互联网创业公司，饿了么从初创到壮大，在移动互联网时代，业务量和技术团队的体量经历了10倍增长，这其中的经历，是互联网领域许多创业公司技术团队的一个缩影。在这里把我们成长过程中的体会和教训记录下来。

饿了么的技术体系，经历了以下四个阶段：

1. 核心系统 All in one 的早期架构；

2. 以系统领域化拆分、业务系统和中间件等基础设施分离为基础的全面服务化的架构；

3. 随着自动化平台、容器调度体系成熟，治理从传统运维向 DevOps 转变的基础设施体系；

4. 多数据中心体系基础上的Cloud Ready架构成型。

在这期间，业务的快速增长，大大小小的事故，组织结构的变化、融合，团队的工程师文化和技术栈背景，不同技术理念的冲突，交织在一起，互相冲击、影响着架构变迁。

第一阶段：All in one

---

这是饿了么技术体系早期的样子，技术联合创始人带着一群 Geek，从0到1，搭建了最早的技术体系，支撑了百万级的单量。

这个阶段，业务一路狂奔，技术拼命追赶业务，唯快不破。

技术栈以 Python 为主，兼有部分 PHP 的系统，单机多应用的混布模式，应用发布、系统运维基本上是开发工程师敲命令行完成。核心的业务系统，商户、用户、交易都共享一个 codebase ，建立在一个名为 zeus 的系统下。短时间内业务飞速增长，在线数据库已经支撑不了 ETL 的需求，大数据体系、数仓开始建立。

大数据所在的上海数据中心，在线业务系统所在的北京数据中心开始搭建，这两个数据中心见证了我们架构的变迁，直到后来整体上云，最早的时候，技术团队40多人，有时候需要创始人跑到机房里面搬服务器。

系统跟不上业务发展速度的时候，核心系统经历过一些间歇性宕机的尴尬阶段。一些刚刚开始开拓的业务系统，也经历了系统刚上线就连续宕机，不得不临时放慢业务的阶段。但是这个过程也有收获，很多开发工程师线上排障能力非常强，脚本玩得很溜。

这个时期的工程师经常一人身兼数职，前端、后端、开发、测试、运维部署，对业务的理解也很深刻，甚至身兼技术和产品的角色。

收获和教训——文化的重要性

早期饿了么有一个鲜明的特点，就是大家都非常有担当，开放且包容。推卸、逃避责任的事情很少发生。虽然当时很多事故回过头来看比较严重，但是，组织对技术人员成长中的错误也相对包容。整个团队比较扁平，上下级之间的技术争论是常有的事情，但是都能就技术论技术。

饿了么的工程师文化氛围还是挺强烈的：工程师想着服务器的资源利用率能不能再压榨一下；在决定大规模使用Redis之前，会去读Redis的源码；很多方案，都是找个吧台和白板快速讨论，快速达成共识，落地上线。可能也是这个氛围&#