饿了么架构
除了美团外卖之外,饿了么,我们大家也时非常熟悉。当初,饿了么平台订单的数量在一定时间内也经历过井喷期,下通过学习云时代架构的文章,我对饿了么的架构进化升级有了一定程度的了解。
在2014年初,饿了么订单量只有日均10万单,到2014年底超过百万,这是一个质的飞跃,10万订单的量级和百万订单的量级的要求非常不一样。在2015年突破了日均300万,到今年5月单日峰值突破500万。快速发展涉及很多问题。大家都知道,饿了么是一家新兴的公司,在美团之后发展起来的,那么随着业务发展非常快,也就 会带来一系列的问题。可能准备不是很充分,比如说监控、日志、告警、框架、消息、数据库,很多基础设施还在建设之中。在这个过程中出现一些问题是在所难免的,对系统的要求不是不能挂、不能出问题,而是出了问题要第一时间能恢复。这是整个系统架构的前提。下午是早起饿了么订单架构的图解。
图中所示是订单的早期架构图,比较简单。这个架构在2014年的时候支撑了日均10万的订单,是一套很不错的架构,依然在很多系统中完美运行。但是对于后来发展的场景,它已经曝露问题了,比如业务逻辑严重耦合、代码管理很困难,因为数据库都在一起,操作变更很难追溯。
更进一步的是,性能的瓶颈只能是靠服务器去硬抗,从物理架构到逻辑架构,都已经成为业务发展的掣肘了。于是,为了业务的发展,我们做了一些演进的工作。
演进工作的核心就是一个字“拆”,跟“拆”对等的就是分治的思想。怎么拆分呢?面向服务有很多拆分原则。我将拆分过程中最具帮助和指导性的点罗列了以下几条。
- 第一是明确的定义。之前也确实犯了一些错误,为了拆而拆。其实我们需要更明确,什么才算是一个服务?服务一定具有非常独立的技术能力或者业务能力,而且一定意义上能够很抽象。
- 第二是松耦合。最基本的松耦合就是Customer的消费不依赖于Provider的某一个特定实现,这样服务器的内部变更不会影响外部消费,消费者可以切换到其他服务能力的提供方,这是最基本的松耦合。还有时间上的松耦合或者位置上的松耦合,我们希望的松耦合是消费方和服务方是可以分离的。
- 第三是基于领域的认知,这对于整个产品起到非常大的作用。因为当时整个饿了么所有系统是在一起的,基于领域的认知,在面向用户的维度和面向商户的维度做了切分,还有基于交易链路做了切分。
- 第四是单一职责和关注分离。简单说,我们希望一个服务或者一个模块拥有单一的能力,而不是承担过多的职责,否则责任不清晰,导致能力也不清晰。
- 最后一点是可被验证的结果。在订单拆分的过程中我们犯了一些错误,当时认为这样拆分是没有问题的,但是过一、两个月,并没有带来效率和能力的提升,反而是跨团队的要求越来越多,能力要求也越来越多。这时候可能是拆错了。如果是一个好的拆分一定有利于发展,拆分之后的发展是更迅速的。
通过对饿了么订单架构的升级学习分析,我更加理解了上课王老师经常强调的分而治之的思想。对于一个具体的宏观问题,我们采取分而治之的策略,将问题逐步进行分解。