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

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

ID:12495770

大小:1.52 MB

页数:29页

时间:2018-07-17

互联网多活技术架构及运维_第1页
互联网多活技术架构及运维_第2页
互联网多活技术架构及运维_第3页
互联网多活技术架构及运维_第4页
互联网多活技术架构及运维_第5页
资源描述:

《互联网多活技术架构及运维》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、互联网多活技术架构及运维饿了么多活系统架构29饿了么业务快速发展,给技术带来了海量请求和高并发、微服务的挑战,同时开发团队快节奏的版本迭代和服务快速上线的要求也驱动运维团队提供稳定、高效的运维服务。我是饿了么的技术运营负责人,见证了饿了么业务的飞速发展。记得2015年加入饿了么的时候,我们的日订单量只有30万笔;而到了2017年,我们的日订单量已经超过1000万笔。考虑到我们在整个市场的体量和单个机房至多只能处理2000万笔订单的上限,我们逐步推进了面向百分之百冗余多活的新规划。29今天的分享主要分为三个部分:·多活场景及业务形态·饿了么多活运维挑战·饿了么

2、运营体系探索多活场景及业务形态饿了么多活的现状首先介绍一下饿了么整个多活的现状:我们在北京和上海共有两个机房提供生产服务。机房和ezone是两个不同的概念,一个机房可以扩展多个ezone,目前是一对一关系。29我们还有两个部署在公有云的接入点,作为全国流量请求入口。它们分别受理南北方的部分流量请求,接入点都部署在阿里云上面,同时从运维容灾角度出发。我们考虑到两个云入口同时“宕掉”的可能性,正在筹建IDC内的备用接入点,作为灾备的方案。多活从2017年5月份的第一次演练成功到现在,我们经历过16次整体性的多活切换。这16次切换既包含正常的演练,也包含由于发生故

3、障而进行的真实切换。其中,最近的一次切换是因为我们上海机房的公网出口发生了故障,我们将其所有流量都切换到了北京。实现多活的背景下面我从五方面介绍实施多活之前的一些背景状况:29·业务特点·技术复杂·运维兜底·故障频发·机房容量业务特点:我们有三大流量入口,分别是用户端、商户端以及骑手端。一个典型的下单流程是:用户打开App 产生一个订单,店家在商户端进行接单,然后生成一个物流派送服务的运单。而该流程与传统电商订单的区别在于:如果在商城生成一个订单,后台商户端可以到第二天才收到,这种延时并无大碍。29但是对于饿了么就不行,外卖的时效性要求很高,如果在10分钟之

4、内商户还未接单的话,用户要么会去投诉,要么可能就会取消订单,更换美团、百度外卖,从而会造成用户的流失。另外,我们也有很强的地域性。比如说在上海生成的订单,一般只适用于上海本地区,而不会需要送到其他地方。同时,我们的业务也有着明显的峰值,上午的高峰,一般在11点;而下午则会是在5点到6点之间。我们通过整个监控曲线便可对全链路的请求一目了然。这就是我们公司乃至整个外卖行业的业务特点。29技术复杂:上图是流量请求从进入到底层的整个技术架构。SOA(面向服务的体系结构)系统架构本身并不复杂,其实大部分互联网公司的技术架构演进到最后都是类似的。我们真正的复杂之处在于:

5、各种组件、基础设施以及整个的接入层存在多语言的问题。在2015年之前,我们的前端是用PHP写的,而后端则是Python写的。在经历了两年的演进之后,我们现在已把所有由PHP语言写的部分都替换掉了。而为了适用多种语言,我们的组件不得不为某一种语言多做一次适配。比如说:我们要跟踪(trace)整个链路,而且用到了多种语言,那么我们就要为之研发出多种SDK,并需要花大量的成本去维护这些SDK。可见,复杂性往往不在于我们有多少组件,而是我们要为每一种组件所提供的维护上。29我们当前的整个SOA框架体系主要面向两种语言:Python和Java,逐渐改造成更多地面向Ja

6、va。中间的APIEverything包含了许多为不同的应用场景而开发的各种API项目。而我们基础设施方面,主要包括了整个存储与缓存,以及公有云和私有云。运维兜底:在业务飞速发展的过程当中,我们的运维团队做得更多的还是“兜底”工作。29最新的统计,我们现在有将近16000台服务器、1600个应用、1000名开发人员、4个物理IDC、以及部署了防护层的两朵云。也有一些非常小的第三方云服务平台,包括AWS和阿里聚石塔等。在业务增长过程当中,基于整个IDC的基础设施环境,我们对交付的机型统一定制,并且改进了采购的供应链,包括:标准化的整机柜交付和数据清洗等。对于应

7、用使用的数据库与缓存,我们也做了大量的资源拆分与改造工作,比如数据库,改造关键路径隔离,垂直拆分,sharding,SQL审核,接入数据库中间件dal,对缓存redis使用治理,迁移自研的rediscluster代理corvus,联合框架实现存储使用的规范化,服务化。曾经面临比较大的挑战是数据库DDL,表设计在每家公司都有一些自己的特点,例如阿里、百度他们每周DDL次数很少。但是我们每周则会有将近三位数的DDL变更,这和项目文化以及业务交付有关。29DBA团队以及DAL团队为此做了几件事情:表数据量红线,基于Gh-OST改进onlineschemachang

8、e工具,Edb自助发布。这样大大减少了数据库DDL事

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。