饿了么：日订单量超900万的架构设计及演进之路

《饿了么：日订单量超900万的架构设计及演进之路》要点：
本文介绍了饿了么：日订单量超900万的架构设计及演进之路，希望对您有用。如果有疑问，可以联系我们。

网站在刚开始的时候大概只是一个想法：一个产业的模型,快速地将它产生出来.“快”是第一位的,不需要花太多精力在架构设计上.在网站进入扩张期才需要对架构投入更多的精力来承载网站在爆发时的流量.

饿了么成立已经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小时在线工作,出了问题找不到人怎么办?如果是有专人来执行回退,而又没有简单、统一的回退操作,那这个人需要熟悉发布人员的代码,这基本上不可行.

所以我们就需要有发布系统,发布系统定义了统一的回退操作,所有服务必须遵循发布系统的定义回退操作.

在饿了么对接发布系统是对所有人的强制要求,所有的系统必须全部接入发布系统.发布系统的框架很重要,这个东西其实对于公司是很重要的一件事情,需要放到第一优先级的队列里面去考虑.

四、服务框架

紧接着就是饿了么的服务框架,把一个大的Repo拆分成一个小的Repo,把一个大的服务拆成一个小的服务,让我们的服务尽量独立出去,这需要一套分布式服务框架来支撑.

分布式服务框架包含的服务注册、发现、负载均衡、路由、流控、熔断、降级等功能,这里就不一一展开了.前面已经提及,饿了么是多语言的生态,有 Python的,也有Java的,我们的服务化框架对应也是多语言的.这对我们后来一些中间件的选型是有影响的,比如说DAL层.

五、DAL数据访问层

当业务量越来越大的时候,数据库会变成一个瓶颈.

前期可以通过提升硬件的方式来提升数据库的性能.比如：

• 升级到一个有更多CPU的机器；
• 把硬盘改成 SSD 的或者更高级一点的.

（编辑：源码门户网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!