阿里巴巴运维中台的演进与建设

《阿里巴巴运维中台的演进与建设》要点：
本文介绍了阿里巴巴运维中台的演进与建设，希望对您有用。如果有疑问，可以联系我们。

作者简介：

毛茂德

阿里巴巴 基础架构事业群运维中台负责人

花名如柏,现任阿里巴巴集团基础架构事业群－运维中台负责人, 主导架构设计高可靠、高并发、大规模的基础运维平台和应用运维平台, 致力于打造行业级的基础运维无人值守解决方案以及数据化、智能化运维解决方案,推动 DevOps 生态.

前言

本文来自于 GOPS 2017 深圳站的演讲“阿里巴巴运维中台的演进与建设”.

我所在的部门是阿里基础架构事业群,负责阿里巴巴的 IDC 建设、网络建设、基础数据库的运维,大数据运维,研发协同,应用运维等等都在我们这个部门里面.

我的团队主要负责运维平台和工具的建设,旨在提升业务交付的效率和运维的自动化、智能化.在去年我们团队名字改成了“运维中台”,名字的改变很重要,他让我们的定位更加清晰,做事更聚焦和专注.

运维平台建设已经很多年,产品比较多,下面我将介绍几个比较重要的产品来呈现阿里运维中台建设的过程.

一、运维基础平台——StarAgent

StarAgent 在阿里已经有五六年,甚至更早的时间.阿里所有的物理机、虚拟机以及容器都会装这个 agent,StarAgent 是管理所有 agent 的系统,基本上要和机器交互都需要通过这个平台.

StarAgent 是一个生态平台,实际上不会做具体的业务,具体的业务还是通过各个业务平台去实现的.它们要和服务器进行交互必须通过我们这个平台.

例如,应用运维平台——诺曼底也是通过 StarAgent 在机器上进行部署发布的.我们希望将 StarAgent 建设成一个平台,而不是所有的业务都是我们来做的.

平台化的项目是2015年底启动的,在此之前机器上运行的 agent 所有的功能整个打包成一个可执行的程序,这导致了研发迭代速度非常缓慢,问题非常多.

我们曾经有一个功能花了一个多月时间开发了一个功能,开始上线,全网做灰度,将近一个时间等快灰度结束的时候,突然发现某些环境下这个功能有 bug,结果又用了一个月的时间回滚.

这个对我们士气是非常伤的,三个月过去了什么业务结果都没拿到.

平台化的改造中,我们把各个业务的功能都变成一个个插件,可以插到这个平台上来.平台只负责最基本的插件维护的功能,以及命令执行的功能,仅此而已.监控、日志采集等功能都变成插件,而不需要都打包在一起.

目前我们平台上已经有了将近90个插件,比如说监控、日志、安全、调度、采集、P2P 文件分发、配置管理类似 puppet, saltstack 等等插件.

而且平台化之前我们必须全网发布,插件化之后,我们可以选择插件的发布范围,开发迭代的速度也有了大幅度提升.

• 平台化之前整个 agent 都需要放到装机镜像里,装机镜像测试也需要一个月时间,所以更新镜像也非常繁琐.
• 平台化之后装机镜像里也只要装基本的 agent core 就可以了,核心插件都可以装机后第一次启动时自动更新即可,这样也不需要频繁的更新装机镜像,core 的功能因为非常纯粹简单,core 稳定之后,更新的频率自然就低到了极致.

StarAgent 平台化之后的架构比较简单,整个 agent 最核心的东西就是管理和运行这些插件,基于一个非常简单的交互协议与插件通讯.只要实现这些接口就可以作为一个插件让 agent 帮你去运维.

所以除了之前 StarAgent 的功能插件化外,我们收敛了机器上众多的 agent,在这之前插件都是自己做一个运维系统,要管理自己的状态,要进行版本的更新和迭代.

现在在统一的平台上统一的进行管理、统一做变更的升级.除了节省运维资源外,同时也能收敛重复功能的 agent,从另外一个角度保证了服务器运维的安全.

1.1 StarAgent核心功能

StarAgent 核心功能就是一个命令的通道,它既可以同步执行任务又可以异步执行任务,还可以查询任务状态和插件管理.插件分为两种,一种是静态的,静态的实际上就是脚本、命令之类的.

另一种动态的是一个常驻进程,必须常驻在系统里面.我们会守护这个进程,如果它挂了会重新拉起来,如果其占用内存、CPU 超过设定的范围会删掉它.整个协议是比较简单的,使用起来耦合度也是比较低的.

1.2 StarAgent特性

StarAgent 系统从功能上来讲是比较简单的,我们其实是花了大量时间在做一些非功能上的东西.

例如,高可用、高并发、安全,还有自运维能力,即使是百万级服务器的场景下,我们的运维人力投入可能几乎为0,我们追求的就是无人值守的运维.

目前这套系统的执行成功率差不多有 99.995% 左右,由于执行量非常大,0.005% 失败率的运维成本还是挺高的.我们花了大量的时间做容灾和自恢复的工作.

前两年支付宝官网瘫痪,经过这个事件我们开始做容灾的演练.把网线拔了,看所有系统的反应,过两个小时再把网线插上去,看这个系统是不是能自动恢复.

以前我们都是半夜三点起来去重启服务器,经过自动化的运维,所有的系统断网都可以自动恢复、服务器可以自动进行扩容,保证系统持续的可用性.

1.3 StarAgent 场景

现在的场景会贯穿整个物理机的生命周期,阿里巴巴在物理机装机的过程中就会用到 StarAgent,从生产到下线整个过程都离不开.

应用运维方面,我们在做重启、发布恢复等等,同时还有监控、数据采集及数据库等方面.

StarAgent 是三层的架构,中央的一层,第二层是每个机房都有管控服务器,最下面一层就是每台服务器安装的 agent 及其插件.

agent 会先注册到管控服务器然后上报自己的信息并且每隔一段时间上报自己的心跳.命令是从上往下的,是通过 API 去下发的.

例如,下发一万台服务器执行命令,所有的命令都是同样的中央服务器,所以它是中央式的架构.

阿里现在有很多走国际化,在俄罗斯、美国、印尼等地收购很多公司,它们的机房也需要我们做运维.目前我们在做的就是去单中心走向多中心的架构.

比如说,在印度尼西亚的一个机房还需要回到中央服务器来再下发,这个路径会非常曲折,我们需要做个多组型.

在国外的我们会多布一个中心,这样的话在单元内可以自制,不需要跑到杭州或上海来再下发到国外机房.

1.4 StarAgent 指标

目前内部访问量每天在一亿多次,但是阿里的服务器还在不断增长,而且随着阿里云的业务逐步扩大,以及阿里本身业务的不断壮大,我们不得不提前考虑未来三年的发展会不会成为瓶颈.

所以去年我们花了半年的时间在架构上做了比较大的升级,目前集群的QPS已经达到55万次/分钟,这个量实际上已经差不多可以支撑未来3年服务器的发展和业务的发展.

以前这些数据都没有,我觉得做运维系统需要把度量这个事情做起来.

 

在架构里面有句话叫没有度量就没有改善,度量是非常重要的.如果产品的核心指标(稳定性、性能、内存占用等)没有定出来,或者无法度量,怎样去架构和优化系统就比较困难,无从下手.

产品的亮点、竞争力、差异性也无从谈起.

实际上系统稳定性以前根本就没有.一个系统指令发过去了就告诉你失败了,不知道什么原因,根本没有错误的分类.然后一堆人开始查问题,查半天发现这台机器磁盘满了.

对于这种方式,我们觉得是不可持续的.我们需要从日志和标准化等方面一定要说清楚系统本身到底有没有问题.

对于第三方依赖,可能是数据库、也可能是一个配置等等,一定要搞清楚第三方依赖的稳定性到底怎么样.对于环境的问题,网络是不是断了,磁盘是不是满了.

这些也都需要在错误码日志里面体现出来,这样才能从各个方面逐步完善系统的指标,否则是没有办法完成的.系统的稳定性非常重要,有了这些数据,系统就可以进行数据化运维.

1.5 StarAgent 插件系统

StarAgent 插件系统,协议很简单.可实现启动、停止,配置如何重新加载等.我们对 CPU 会做一些守护,同时会做一些一键部署的事情.

原来我们升级插件是非常多的,服务器数据很大,再加上插件数量和插件各种版本,这个量是非常巨大的.

以前全网升级插件差不多要六个小时,经过优化之后现在大约10分钟就可以了.

二、文件分发系统——蜻蜓

对于全网都需要用到的,这些就不是一个个性化的需求,这些这插件是我们自己来开发.比如蜻蜓(P2P文件分发系统)就是我们自己开发的.

文件分发其实是我们做部署系统的优化时候去做的,当时比较纠结,是自己开发还是用现成的系统.我们对比了业界很多类似的技术.

比如 Facebook 的 wdt (https://github.com/facebook/wdt),Twitter 的 ( https://github.com/lg/murder ),百度的 Ginko 等等,还有包括亚马逊 Apollo 里面的文件分发系统,它们那个和我们的有点不太一样,他们的是基于 S3 做的.

我们发现他们各自或多或少的都有些问题,无法满足我们多种场景下应用需求.这个产品可以不夸张的说已经做到行业第一.

蜻蜓系统是纯碎的 P2P 的文件分发系统.在做 Docker 过程中,如果没有系统解决这些问题,整个 Docker 化的进程就会受到影响.当到了一定量以后根本就支撑不了,所以直接把镜像仓库的协议全部都实现了一遍.

2.1 蜻蜓核心功能

P2P 的文件分发我们做了很多特性,包括多线程下载、一致性校验以及白名单控制等.

有些业务对磁盘是非常敏感的,例如搜索类的业务,所以会要求在写这个智能 IO 的时候会有些控制,我们会把这个参数调出来通过这个参数对磁盘进行管理.

一个 200M 的文件在传输的时候会变得比较小,网络和传输速度都会得到优化.

2.2 蜻蜓业务指标

蜻蜓系统目前是一万个客户端同时下载 500M 的文件平均耗时 5s.阿里集团大部分的文件分发都统一用了这套系统.下载次数是 12万/月到 3亿/月.系统稳定性达6个9.也是自运维的系统.

使用蜻蜓系统和不用该系统进行对比可知,这个模式下载速度会快很多而且不会随着并发数量上升而严重延时.

三、应用运维平台——Normandy

Normandy 是运维整个阿里巴巴业务的 PaaS 平台.这个平台实际上提供三大功能,分别是基础设施即代码(Infrastructure as Code)、部署和应用运维支撑.

我们希望能够通过代码描述文件的形式把一个应用需要用到的所有资源,包括机载资源、服务器、网络还有数据库等都描述出来,这样就可以能够快速构建一个应用.

应用已经有了,如何把代码部署到线上,让其能够对外提供服务,这就需要部署发布了.在发布部署方面我们做了无人监守的发布,我们和中间件等部分做了整合,只要代码没有出现线上的故障就可以自动发完.

如果出现故障发布就会停下来,此时需要人介入去判断要不要作维稳.亚马逊的发布系统阿波罗,一年的发布量差不多是五千万,据说现在一天的发布量已经能达到50万.

去年在这方面我们也做了很多工作,至少说这个发布系统不会因为业务发布次数比较大导致发布系统挂掉.

另外,现在整套系统已经将阿里巴巴的测试环境和线上环境全部打通,解决了线上系统和测试不统一的情况.

目前业务方有很多的平台使用应用运维平台和运维基础平台 StarAgent.从应用数量上来讲,实际上也是最多的,大概 80% 的应用都基本集中在交易.

阿里云稍微有点特殊,有一半对 ECS 的运维,ECS 也是要做发布与运维,ECS 今年努力的方向要尽量做到不影响用户.

以上的产品都是服务于整个阿里巴巴集团的,这些服务都是最基础的,我们的核心能力基本都是通用的,不带业务的特殊性,特殊性的功能可以在我们的平台化上进行扩展.

这就是中台的原义,中台的好处就是让业务能根据自己的特性在中台上快速的发展,而不需要一杆子桶到最底层,同时中台也没有能力去帮助每个业务去实现所有的特性功能.

这个是整个做事方式的转变,每层都想清楚自己的核心能力,做什么,不做什么同样重要.

在满足了集团业务运维的同时,我们这些产品也真正的在打磨极致产品特性,极致的稳定性、极致的性能、极致的体验.

这样能提升产品的竞争力,拉高进入门槛,光是一堆运维功能堆砌的产品是咩有灵魂的,也非常容易被复制.

我们的产品在今年就会完成单元化,国际化,云化,希望能成为云上有竞争力的运维产品.

文章来自微信公众号：高效运维

转载请注明本页网址：
http://www.vephp.com/jiaocheng/2711.html