互联网多活技术架构及运维.docx

互联网多活技术架构及运维.docx互联网多活技术架构及运维
饿了么多活系统架构
饿了么业务快速发展,给技术带来了海量请求和高并发、微服务的挑战,同时开发团队快节奏的版本迭代和服务快速上线的要求也驱动运维团队提供稳定、高效的运维服务。
我是饿了么的技术运营负责人,见证了饿了么业务的飞速发展。记得 2015 年加入饿了么的时候,我们的日订单量只有 30 万笔;而到了 2017 年,我们的日订单量已经超过 1000 万笔。
考虑到我们在整个市场的体量和单个机房至多只能处理 2000 万笔订单的上限,我们逐步推进了面向百分之百冗余多活的新规划。
今天的分享主要分为三个部分:
多活场景及业务形态
饿了么多活运维挑战
饿了么运营体系探索
多活场景及业务形态
饿了么多活的现状
首先介绍一下饿了么整个多活的现状:我们在北京和上海共有两个机房提供生产服务。机房和 ezone 是两个不同的概念,一个机房可以扩展多个 ezone,目前是一对一关系。
我们还有两个部署在公有云的接入点,作为全国流量请求入口。它们分别受理南北方的部分流量请求,接入点都部署在阿里云上面,同时从运维容灾角度出发。
我们考虑到两个云入口同时“宕掉”的可能性,正在筹建 IDC 内的备用接入点,作为灾备的方案。
多活从 2017 年 5 月份的第一次演练成功到现在,我们经历过 16 次整体性的多活切换。
这 16 次切换既包含正常的演练,也包含由于发生故障而进行的真实切换。其中,最近的一次切换是因为我们上海机房的公网出口发生了故障,我们将其所有流量都切换到了北京。
实现多活的背景
下面我从五方面介绍实施多活之前的一些背景状况:
业务特点
技术复杂
运维兜底
故障频发
机房容量
业务特点:我们有三大流量入口,分别是用户端、商户端以及骑手端。
一个典型的下单流程是:用户打开 App 产生一个订单,店家在商户端进行接单,然后生成一个物流派送服务的运单。
而该流程与传统电商订单的区别在于:如果在商城生成一个订单,后台商户端可以到第二天才收到,这种延时并无大碍。
但是对于饿了么就不行,外卖的时效性要求很高,如果在 10 分钟之内商户还未接单的话,用户要么会去投诉,要么可能就会取消订单,更换美团、百度外卖,从而会造成用户的流失。
另外,我们也有很强的地域性。比如说在上海生成的订单,一般只适用于上海本地区,而不会需要送到其他地方。
同时,我们的业务也有着明显的峰值,上午的高峰,一般在 11 点;而下午则会是在 5 点到 6 点之间。
我们通过整个监控曲线便可对全链路的请求一目了然。这就是我们公司乃至整个外卖行业的业务特点。
技术复杂:上图是流量请求从进入到底层的整个技术架构。
SOA(面向服务的体系结构)系统架构本身并不复杂,其实大部分互联网公司的技术架构演进到最后都是类似的。
我们真正的复杂之处在于:各种组件、基础设施以及整个的接入层存在多语言的问题。
在 2015 年之前,我们的前端是用 PHP 写的,而后端则是 Python 写的。在经历了两年的演进之后,我们现在已把所有由 PHP 语言写的部分都替换掉了。而为了适用多种语言,我们的组件不得不为某一种语言多做一次适配。
比如说:我们要跟踪(trace)整个链路,而且用到了多种语言,那么我们就要为之研发出多种 SDK,并需要花大量的成本去维护这些 SDK。
可见,复杂性往往不在于我们有多少组件,而是我们要为每一种组件所提供的维护上。
我们当前的整个 SOA 框架体系主要面向两种语言:Python 和 Java,逐渐改造成更多地面向 Java。
中间的 API Everything 包含了许多为不同的应用场景而开发的各种 API 项目。而我们基础设施方面,主要包括了整个存储与缓存,以及公有云和私有云。
运维兜底:在业务飞速发展的过程当中,我们的运维团队做得更多的还是“兜底”工作。
最新的统计,我们现在有将近 16000 台服务器、1600 个应用、1000 名开发人员、4 个物理 IDC、以及部署了防护层的两朵云。也有一些非常小的第三方云服务平台,包括 AWS 和阿里聚石塔等。
在业务增长过程当中,基于整个 IDC 的基础设施环境,我们对交付的机型统一定制,并且改进了采购的供应链,包括:标准化的整机柜交付和数据清洗等。
对于应用使用的数据库与缓存,我们也做了大量的资源拆分与改造工作,比如数据库,改造关键路径隔离,垂直拆分,sharding,SQL 审核,接入数据库中间件dal,对缓存 redis 使用治理,迁移自研的 redis cluster 代理 corvus,联合框架实现存储使用的规范化,服务化。
曾经面临比较大的挑战是数据库 DDL,表设计在每家公司都有一些自己的特点,例如阿里、百度他