饿了么：业务井喷时,订单系统架构这样演进饿了么：业务井喷时,订单系统架构这样演进.pdfVIP

饿了么 ：业务井喷时 ，订单系统架构这样演进 在高速增长和愈加复杂的 易场景下 ，饿了么订单的服务架构是如何演进的 ？如何发展 ？ 本文根据石佳宁在Inf o Q举办的2016A rchSummit 全球架构师 （深圳 ）峰会上的演讲整理而成 ： 先自我介绍一下 ，我于2014年加入饿了么 ，那时正是饿了么飞速发展的起始点。我一直从事后台领 域的研发 ，比如BD系统、客服系统和订单系统 ，现在专注 易架构相关的工作。 今天要讲的内容主要分为两大部分。第一部分是在高速增长和愈加复杂的 易场景下 ，饿了么订单 的服务架构是如何演进的 ，究竟是什么支撑我们的发展。 快 增长下的业务场景 具体讲之前 ，我先介绍一下我们的场景 ，因为脱离具体的场景所有架构演进没有任何意义。 上面这 两个图表不是饿了么的数据 ，是第三方分析整个外卖市场的数据图。左边的图表是从2011年开始 ， 整个O2O市场以及外卖的份额逐年增加。2013年和2014年的时候发生了比较大的飞跃 ，饿了么也 是在这个时间段订单量开始猛增。右边的图表是用户注重外卖平台的因素分布。 从图中可以看到 ，用户很在意配送速度 ，在意 易的时效性。对于O2O或者饿了么订单 ， 易的要 求比传统电商的高 ，因为 易一般一两个小时就结束了。在2014年初 ，饿了么订单量只有日均10 万单 ，到2014年底超过百万 ，这是一个质的飞跃 ，10万订单的量级和百万订单的量级的要求非常 不一样。在2015年突破了日均300万 ，到今年5月单日峰值突破500万。 快 发展涉及很多问题。我们是一家创业公司 ，业务发展非常快 ，可能准备不是很充分 ，比如说 监控、日志、告警、框架、消息、数据库 ，很多基础设施还在建设之中。在这个过程中出现一些问 题是在所难免的 ，对系统的要求不是不能挂、不能出问题 ，而是出了问题要第一时间能恢复。这是 整个系统架构的前提。 服务架构的演进 图中所示是订单的早期架构图 ，比较简单。这个架构在2014年的时候支撑了日均10万的订单 ，是 一套很不错的架构 ，依然在很多系统中完美运行。但是对于后来发展的场景 ，它已经曝露问题了 ， 比如业务逻辑严重耦合、代码管理很困难 ，因为数据库都在一起 ，操作变更很难追溯。 更进一步的是 ，性能的瓶颈只能是靠服务器去硬抗 ，从物理架构到逻辑架构 ，都已经成为业务发展 的掣肘了。于是 ，为了业务的发展 ，我们做了一些演进的工作。 演进工作的核心就是一个字“拆” ，跟“拆”对等的就是分治的思想。 怎么拆分呢 ？面向服务有很多拆分 原则。我将拆分过程中最具帮助和指导性的点罗列了以下几条 ： 第一是明确的定义。之前也确实犯了一些错误 ，为了拆而拆。其实我们需要更明确 ，什么才算是 一个服务 ？服务一定具有非常独立的技术能力或者业务能力 ，而且一定意义上能够很抽象。 第二是松耦合。最基本的松耦合就是Cust o mer的消费不依赖于Provi er的某一个特定实现 ，这样 服务器的内部变更不会影响外部消费 ，消费者可以切换到其他服务能力的提供方 ，这是最基本的松 耦合。还有时间上的松耦合或者位置上的松耦合 ，我们希望的松耦合是消费方和服务方是可以分 离的。 第三是基于领域的认知 ，这对于整个产品起到非常大的作用。 因为当时整个饿了么所有系统是在 一起的 ，基于领域的认知 ，在面向用户的维度和面向商户的维度做了切分 ，还有基于 易链路做了 切分。 第四是单一职责和关注分离。简单说 ，我们希望一个服务或者一个模块拥有单一的能力 ，而不是 承担过多的职责 ，否则责任不清晰 ，导致能力也不清晰。 最后一点是可被验证的结果。在订单拆分的过程中我们犯了一些错误 ，当时认为这样拆分是没有 最后一点是可被验证的结果。在订单拆分的过程中我们犯了一些错误 ，当时认为这样拆分是没有 问题的 ，但是过一、两个月 ，并没有带来效率和能力的提升 ，反而是跨团队的要求越来越多 ，能力 要求也越来越多。这时候可能是拆错了。如果是一个好的拆分一定有利于发展 ，拆分之后的发展是 更迅速的。 基于这几条原则 ，我们对饿了么的整体服务做拆分之后 ，如上图所示 ，架构就有了一些变化 ，看起 来跟刚才架构区别不大。把O r er Service做了分离。当时拆分虽然比较垂直 ，但是用户、商户、 金融、订单等还是有一些横向 互。 一个接口有一个非常明确的Ow ner ，一个表、一个库也能保证仅有单一的操作方 ，让我感受比较直 接的是 ，为服务的治理奠定了基础 ，以后可以针对某项特定业务做一些降级、熔断 ，以及单独的 监控。拆分实际上是让各自模块的掌控力变得更强了