饿了么资深架构师分享云上基础架构演进

Posted 2021-12-28 弹性计算百晓生

从单体应用到微服务体系再到多活架构，从用云到IaaS全面上云再PaaS上云，最后全面拥抱云原生，这就是饿了么的云上基础架构演进之路。

【图：饿了么资深架构师朱琳骐】

 

12月10日，饿了么资深架构师朱琳骐在2021云上架构与运维峰会上，分享了饿了么云上基础架构的演进历程。以下是他的演讲实录：

 

经过10多年的运营，饿了么的业务不仅从起步时的个位数的订单成长到了现在的千万级别，同时还完成了从外卖业务到“爱什么来什么”综合业务形态的演进。我会以业务的需求和变化为主线，聊一聊这10多年我们的技术是如何演进的。

 

一、架构的演进历程

 

2014年前饿了么和传统的技术性公司并没有特别大的区别，主要是以传统的独立应用方式来进行部署。随着移动互联网的兴起，外卖业务迅猛发展，传统模式的架构只能支撑百万单量。为了支撑业务的灵活多变和不断提升的单量，饿了么进行两次非常大的技术升级。

 

 

2014年到2017年，饿了么完成了从单体应用到微服务体系的技术改造。2017年完成了多活架构的演进，2018年到2021年9月，完成了从用云到IaaS全面上云和PaaS上云三个重要的里程碑，目前饿了么也在构建基于云原生新的架构体系。

 

二、云计算—基础架构升级1.0

 

一切技术的演进都是为了满足业务的诉求，业务狂奔促成了饿了么，也促使其完成了从单体到多活架构的演进。

 

01  传统架构

 

传统单体架构有着耦合度高、交付慢、运维效率低下等诸多缺陷。随着业务架构的调整，单体服务也逐步按照领域进行了微服务体系的升级。

 

 

为了提升运维效率、交付效率和稳定性，我们构建出了elss、appos、ice 3三位一体的自动化发布平台，来提升产业的交付效率；还有自研的maxq（当时的rabbitmq无法支撑业务单量）、apirouter、covrus、dal等多个中间件，以及Pylon+huskar微服务框架来增强业务的扩展能力；结合7×24小时的团队实时监控，来大幅的提升排障和响应的能力，整体的技术体系也逐步向DevOps演进，完成从单体到微服务架构的演变。

 

02  异地多活和用云

 

2017年，上海机房出现瓶颈，传统的同城双活已经没有办法满足我们的需求，而异地多活对于任何一个技术团队来说都是非常大的挑战。后续经过各方共同努力，耗时3个月，多活成功上线。接下来简单介绍一下多活相关的组件。

 

DRC主要是做数据同步，dal在切流的时候做一些数据禁写工作， APIrouter会在Gzs的调度下进行机房之间的流量切换。中间的Soaproxy除了单元内寻址以外，也要在和集团业务有交互的情况下，来进行单元选址。

 

多活上线后，除了解决业务的容量问题，也为饿了么的稳定性提供了坚实的后盾。

 

 

上图深色部分是在云上构建的。多活上线以后我们急需资源，按照传统的预算采购再进行部署没有办法跟上我们的节奏，所以必须借助于云上的弹性能力来构建alpha和alt2两套完整的测试环境，这样我们就可以随时根据业务的需求进行容量调整。

 

互联网的大促是每年的传统，自建的机房早在年初就规划好了，如果我们每年都按照大促的规模进行部署，将有大量的资源被浪费掉。因此我们不只把网关搬到云上，其中一个机房也在云上重新进行了构建。此后，我们只需要在大促前做好云上的扩容就可以了。活动结束后，一键操作缩容即可，节省了大量的成本和时间。

 

除了大促，薅羊毛也是互联网特有的。为了避免黑产薅羊毛，网关在云上构建的同时，也直接使用了阿里云的tfe来进行流量清洗，安全性能得到了大的提升，而这个对饿了么来说只是付费然后开箱即得的简单操作。

 

截至2018年，饿了么完成了基于云计算的基础架构1.0升级，多活体系和Sam中间特殊的中间件，在满足业务的同时，也为二次上云的演进埋下了一个伏笔。

 

三、云原生—基础架构升级2.0

 

01  业务痛点

 

随着2018年饿了么被阿里收购，饿了么从单一的外卖体系演进到了承接本地生活的综合体系，“爱什么来什么”的业务对我们提出了更高的要求。后续饿了么上云，也是与业务痛点息息相关的。

 

 

当时我们面临了以下几大问题：

⚫  WG机房过保稳定性变差。

⚫  为了降低用户的支出，我们需要降低单均成本。

⚫  从单独的外卖业务到本地生活，我们需要快速试错，必须借助弹性能力才能灵活多变。

⚫  经过淘系业务锤炼的中间件，比我们有更高的稳定性和产品能力。

⚫  要进行rpc框架统一，这不仅能满足业务和集团互联互通的诉求，还能节省大量重复建设的成本。

经过对用云红利和业务痛点的分析，最终我们选择了全面上云，在云上对本地生活的基础设施进行全面升级。

 

02  上云策略

 

 

上云规划分为3步。

 

首先从IaaS层开始，将资源网络存储等设施基于云原生进行打造。完成IaaS层上云之后，再进行PaaS上云，采用云上中间件为产研提供服务，还将我们特有的多活相关的中间件基于CloudHosting进行重构，以此完成基于云原生的2.0架构升级。

 

截至2020年5月30号，本地生活IaaS全面上云，这个过程充分体现了阿里云的技术实力。

03  收益

 

接下来分享一下上云的收益。

 

首先基础设施云化之后，合池收益每月494万，年化近6000万。另外借助弹性能力，我们做了ECS水位治理，日均成本下降了9万，年均的收益达到3400万。此外，基础运维的人力节省了5个。

 

第二点是整个发布系统打通，测试环境和集团共用之后，大概降低了30%容量要求。此外，发布系统人力也节省了5个。

 

 

从去年6月份到今年9月份，我们完成了PaaS上云。这个过程我们借用了多活能力，对各种方案进行兜底。另外，前面提到的Sam也在这里起到了非常大的作用，它能够在产研无感的同时完美做到同构中间件的切流。

 

目前为止，微服务体系从Huskar、Pylon迁移到了集团的Pandora、DNS、Sentinel，未来还会再往云上的EDAS进行升级。消息层的kafka已经全部上云，在AMqp开服之后，MAXQ也将会进行升级。代理层已经从SoapProxy升级到HsfProxy，最近饿了么也在和阿里云正在共建中间件4.0，之后就能解决中心化的Proxy问题。存储层的ES已经有70%在云上了，MySQL到RDS的迁移还在项目启动阶段。缓存层的Redis和Ekv已经完全上云了，用了云上的redis和 lindorm。

 

微服务体系打通之后，Proxy只需要保留多单元的寻址能力，使得节点数目缩减50%，节省了大概1万核。同时，替换了DNCS以后，微服务体系的稳定性和能力都有了大幅的增强，包括原来我们没有的灰度能力。人力成本上节省了近10人。

 

第二个大收益点在于中间件上云。首先产品的性能稳定性得到提升，其次大促资源预留成本也明显降低。之前每年都会为了大促额外保留30%的buffer，而现在不需要了。还有基础设施方面的人力成本减少50人。

 

04  未来规划

 

 

饿了么上云项目的结束并不代表技术演进到此停止，业务还在发展，新的技术痛点依然会存在。根据当前的业务痛点，我们进行了新一轮的规划，主要分为三个方面：

 

⚫  完成通用自研中间件到云上中间件的过渡；同时对自研中间件，进行基于云原生环境的改造，进一步增强产品的稳定性和资源的利用率。

 

⚫  构建IaaS层资源平台，云上云下的资源统一收口，提升产业的工作效率；同时也要加强资源利用率的感知和成本治理的平台化；最终借助云上H/VPA能力调度能力，结合业务特性来提升整体的资源利用率。

 

⚫  构建Paas层平台，借助云原生sidecar的部署能力完成从Sam到Envoy升级；增强中间件使用能力，快速定位线上问题；提升中间件能力，如redis数据压缩和分片场景；最后还要保留原来的一些能力，比如资源切换。中间件升级的时候，怎么样保证产研无感以及系统的快速恢复能力，这些都是我们重点要规划的事情。

 

最后，我想强调，对于饿了么来说，云原生不是技术的终点，而是新的生态下的全新起点。

 

点击大会官网，查看朱琳骐在峰会上的精彩演讲视频。