互联网应用系统的架构设计及演进之路.docx

互联网应用系统的架构设计及演进之路网站在刚开始的时候大概只是一个想法：一个产业的模型，快速地将它产生出来。“快”是第一位的，不需要花太多精力在架构设计上。网站进入扩张期才需要对架构投入更多的精力来承载网站在爆发时的流量。饿了么成立已经 8 年，现在日订单量突破 900 万。我们也有了较为完善的网站架构。网站基础架构初期，我们使用了能够更容易拓展 SOA 的框架。我们用 SOA 的框架，解决两件事情：1. 分工协作网站初期，程序员可能就 1~5 个，那时候大家忙同一个事情上就可以了。彼此之间的工作都互相了解，往往是通过“吼”的方式就把问题解决了。但是随着人员的增加，这种方式显然是不行的，不可能一个人更新了代码再把其他人的所有代码重新上线一遍吧？于是就要考虑分工协作的问题。2. 快速扩展以前订单量可能从 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 小时在线工作，出了问题找不到人怎么办？如果是有专人来执行回退，而又没有简单、统一的回退操作，那这个人需要熟悉发布人员的代码，这基本上不可行。所以我们就需要有发布系统，发布系统定义了统一的回退操作，所有服务必须遵循发布系统的定义回退操作。在饿了么对接发布系统是对所有人的强制要求，所有的系