|
|
51CTO旗下网站
|
|
挪动端

微信月活9亿的高效运维之路

微信业务量增长的时分,我们比拟关怀的是服从题目。后期能够两三个月就涨了 1 倍的量,怎样可以包管我们的运营服从是跟得上的?前期次要关怀的是本钱题目。

作者:吴磊泉源:高效运维|2017-12-25 09:16

明天的主题次要是关于弹性伸缩、扩容和缩容这些方面。

微信业务量增长的时分,我们比拟关怀的是服从题目。后期能够两三个月就涨了 1 倍的量,怎样可以包管我们的运营服从是跟得上的?前期次要关怀的是本钱题目。

我们在 2014 年当前增长有点放缓,以是次要的精神会在本钱这个方面。

如上图,上面我次要分为四个方面来做分享:

  • 运营标准。
  • 云化办理。
  • 容量办理。
  • 主动调理。

运营标准

设置装备摆设文件标准

先来看设置装备摆设文件标准,我们后期花了比拟多的精神。能够整个零碎设计比拟庞大,最开端都市有一些设置装备摆设办理工程师专门来处置,前期我们把这块搞得比拟标准了。

设置装备摆设文件标准分为上面几项:

目次构造规范

这便是一个效劳摆设上线的时分怎样界说它的目次构造,各人应该先做好这些目次构造规范的界说。

跨效劳的相反设置装备摆设项办理

为什么提这一点?能够有些设置装备摆设项你会在这个效劳里需求这几个设置装备摆设项,在另一个效劳里也需求这几个设置装备摆设项。

假如变动这个设置装备摆设项的时分,你是不是把效劳 A 发一遍,效劳 B 也发一遍?我们有一套机制,每台机每个目次下都市有一个全局共用的设置装备摆设项,我们会经过一些主动化的灰度的方法来控制这里的公布,这一块是独自拎出来的。

统一效劳内差别实例的差别设置装备摆设项办理

不确定各人运营时会不会遇到相似的题目,就算你用 Docker 了你镜像办理挺好的。

你摆设个实例出来,能够你们的业务就需求在实例 1 上做一些调解,固然你也可以用剧本来办理。

但是我们以为这是比拟庞大的形态,我们会把这些差别性全部给它一致抽取出来,只管即便做到一切的情况下它的设置装备摆设文件的 MD5 都是分歧的。

开辟/测试/现网的差别设置装备摆设项办理

后期也会有这个题目,开辟情况我们普通不论,测试情况也是运维来担任办理,现网固然是运维办理的。

根本上测试和现网的差别只要路由的差别,其他的设置装备摆设项我们都包管它是完全分歧的。

做这么一个要求,大约完成的结果是不论你经过什么手腕扩容,我们间接一个镜像打过来或许间接一个包拷过来就可以了,不会再有后续的剧本来窜改它。

统一效劳下统一版本的多个实例,在一切情况下设置装备摆设文件的 MD5 都严厉分歧。

名字效劳标准

名字效劳这块比拟紧张,分为三层:

  • 接入层,类 LVS 完成。
  • 逻辑层,类 etcd 完成。
  • 存储层,路由设置装备摆设主动化。

效劳伸缩是运维工程,独立于研发的变卦公布。

接入层和逻辑层,都是相似的完成,我们外部依据我们的业务特性做了一些业务开辟。

存储层跟 QQ 有点纷歧样,QQ 仿佛是逻辑层和存储层都是用统一个名字效劳完成,我们在存储层这里还没有做这方面的设置装备摆设。

我们如今存储层跟逻辑层隔得比拟开,在触及到数据的方面,我们差未几可以以为是运维可以设置装备摆设的方法,但是又不完满是可以设置装备摆设,用那些辅佐剧本来设置装备摆设。

效劳伸缩是运维工程,我们不盼望在效劳伸缩时还思索另外要素,独立于研发的变卦公布。

我们有个特点,研发是经过运维提供的变卦零碎,他在下面根本上不需求做什么操纵,整条链就买通了,运维不必关怀变卦公布,只需求管好效劳伸缩就好。

数据存储标准

数据存储标准如下:

  • 接入层,不带数据。
  • 逻辑层,带短周期 cache、带静态数据、制止静态数据落地。
  • 存储层,带长周期 cache、基于 paxos 协议的数据落地。

接入层和逻辑层的效劳伸缩,无需思索数据迁徙和 cache 掷中率。

数据存储方面,独自拎一页出来会以为这个场景是比拟多人中招的,比方接入层一定不会带什么数据的,逻辑层我盼望它是不带数据的,并且我们也严厉要求不带数据的。

常常呈现如许的场景,他的逻辑层要主动伸缩,跑了一段工夫上线了一些逻辑在下面保管了一些数据,在上面做缩容的时分是不是就中招了,会有这个题目,以是我们会定这个标准。

逻辑层是不带数据的,会有静态数据,包罗用户发的音讯、用户发的冤家圈,很分明应该放到存储层的。

接入层不带数据,实在汗青上我们也有一次是带了数据的,在每次过年抢红包的时分,一切人都在摇的那一把,谁人量黑白常恐惧的。

摇红包谁人点我们做设计是每个摇红包的恳求真的打到我们接入层,不会有客户端摇五次才有一次恳求下去。

我们的接入层的功能包管我们能抗住这个量,但是前面的逻辑层一定撑不了这个量,1 秒钟几万万。

这个时分我们会做一些很特别的逻辑,在接入层间接带上红包数据,固然这是比拟特别的场景,我们只在过年的时分这个标准是没有实行的。

运营标准小结

运营标准小结:

  • 阶段目的

效劳可运维

  • 落实步伐

变卦零碎阻拦

全网扫描不标准的效劳

这里说了几点,我们的目的复杂来说便是效劳可运维,可运维的意思便是你做扩容缩容的时分不需求做人工的操纵,假如做人工的操纵便是不行运维。

为了完成效劳可运维,我们在变卦零碎里做了一些阻拦,它接上去变卦能够不契合我们运营标准或许之前有不契合我们运营标准的中央,我们都市拦上去,要求变卦,完成我们的运维标准。

云化办理

接上去说一下云,各人用云也挺多的,近几年也比拟火,能够各人用得比拟多的是 Docker,微信这边我们没有效 Docker,前面也会说到为什么没有效的缘由。

为什么上云

上云的两点缘由:

微效劳总数近 5k。

同物理机上多效劳的资源抢占题目。

先说为什么要上云,在 2013 年、2014 年时,我们的微效劳曾经赴任未几 5000 个。

我是近几年才晓得这个叫微效劳,我们之前完成方法曾经是很多多少年都算微效劳的方法了。

最开端说微效劳这个事变的时分,我记得是 QQ 那里海量运营的一些课程都市提到,我以为这个思绪跟微效劳是完全分歧的。

我们运维这边在完成了一套新效劳公布的时分,根本上不会给研发有什么限定说你这个效劳不要搞太多。

以是整个零碎搞上去谁人量是比拟夸大的,固然就会呈现他的多个效劳要在统一台机上摆设,由于外面有 5000 个微效劳,肯定要同物理机摆设。摆设多个效劳就会有资源抢占,基于这个要素,我们就上云。

哪局部上云

哪局部上云:

  • 接入层,独占物理机、 容量富足、 变卦少。
  • 逻辑层,混淆摆设、 容量不行控、变卦频仍。
  • 存储层,独占物理机、容量可控、变卦少。

哪一块上云,方才也说到,接入层由于要扛住比拟猛的量,微信的用户也比拟多,假如它有什么题目,能够接入层会雪崩。

以是我们次要是独占物理机,容量足,变卦也少,临时没有上云的需求。

在逻辑层这里,之条件到 5000 多个微效劳,以是比拟杂乱,变卦比拟多,容量也不行控,以是这块上了云。

存储层这里,也没有上云,但是有独自的容量办理和数据迁徙。

基于 Cgroup 的云化

基于 Cgroup 的云化:

  • 假造机型定制

VC11 = 1 个 cpu 核 + 1G 内存

VC24 = 2 个 cpu 核 + 4G 内存

  • 物理机分片

我们云的方法是间接 Cgroup,Cgroup 这个名字能够有些人不晓得,我们用的是内核 Cgroup 这种机制。

在现网的时分,用相似复杂的假造机型定制,比方 1 个 cpu+1G 内存。

后期我们也有一些流量要素的思索,厥后把它给取消失了,我们零碎架构上包管的谁人流量仿佛是不怎样会成为题目的。

这里复杂列了一下假造机分片的方法,怎样隔的方法都有,我们隔的这么随意也带来别的一个题目,零碎运转进程中会有一些相似于磁盘碎片的工具存在,就仿佛你 通博8888 跑了好久当前也会有磁盘碎片存在一样。

这个我们也有一些比拟特别的办法来处置。

线上未启用 Docker

我们没有效 Docker 的几点缘由:

  • svrkit 框架 100% 掩盖全网,已完成规范化标准化。
  • 框架自身少量依赖 IPC 交互。
  • 自研非侵入式 vs Docker 侵入式。

Docker 太火了,我们差未几在 2014 年、2015 年的时分,线上也大批上线了一轮。

我们这个 svrkit 框架是我们微信外部自研的一套框架,100% 掩盖全网。

100% 什么意思?一点开源代码都没有,包罗后面各人能够用得最多的 Nginx 做接入,这个我们也是在自研上切换的,包罗前面的存储,后期用了 MySQL,前期也都换成本人的组件了。

现网用我们本人的框架 100% 掩盖了,我们的规范化和标准化都是比拟好的。

可以说Docker处理的一些题目在我们这里不是题目:

  • 我们对 Docker 的需求不是很激烈。
  • 框架自身我们用了许多 IPC 交互,这些工具在 Docker 里都做了很严厉的标准,假如我们用 Docker,能够会把这些 Docker 里的种种机制毁坏失。假如是这种状况,还不如不必 Docker。
  • 我们对 Docker 这种接入方法的完成照旧有顾忌,早一两年有人跟我讨论比拟多,Docker 主历程起来的时分,能够由于要更新 Docker 自身,会招致效劳重启。

仿佛近期曾经处理这个题目,这个在晚期来看我们以为是一个比拟严峻的题目,我不盼望说由于 Docker 自身的变卦,对线上的效劳有任何影响。

公有云调理零碎

基于下面的点,我们自研了一套云化办理的 Docker 零碎。

上图是我们公有云调理零碎:

  • 基于 svrkit 框架自研。
  • 参考 borg/yarn/k8s/mesos 等主流调理零碎的长处。
  • 掩盖 80% 的微效劳。

基于我后面提到的 svrkit 框架+自研,调理零碎固然也要用我们本人的调理零碎掩盖,现在掩盖了 80% 的微效劳,还差一点点 100% 掩盖。

公有云调理零碎架构

这是我们的架构,熟习的人一看就晓得跟业界的事变没有什么区别,两头有一些假造化的坑,可以以为跟各人用得没有太大区别,不细讲了。

云化办理小结

云化办理小结:

  • 阶段目的

效劳间资源断绝

效劳伸缩页面化操纵

  • 落实步伐

摆设零碎阻拦未上云业务

自动改革中心业务

在云化办理这一块,我们完成的一个目的便是资源断绝,Docker 效劳之间不要由于一个效劳非常搞的第二个效劳也非常。

第二是效劳伸缩页面化操纵,有些效劳照旧很巨大的,一个效劳下几千上万台都能够,这种时分不盼望你上呆板的,在页面上点就可以了。

我们为了落实这个目的,会把摆设零碎,把那些没有上云的拦住,他要走旧的摆设方法上线,他需求走旧的流程才干走旧的贸易形式。

后面这些运营标准和云化办理,置信各人多几多少都市有本人的完成方法,也都市有本人的一些总结。前面容量这块不确定各人都是怎样改的。

容量办理

怎样支持业务开展

这是一个业务量增长的曲线,也是我们容量的曲线。

普通来说你扩了一次容就不断均衡在这里,有一个点你发明撑不住了,要扩容,扩上去,就不断坚持这个形态,跟容量曲线是不怎样婚配的。

第一个点是你这个容量低于现网的业务量的时分,这实在是容量缺乏的,能不克不及很快发明这个题目。

第二个点是处置服从,容量缺乏的时分把曲线打上去,扩容需求多永劫间,假如是几天或许几分钟,这个服从是纷歧样的。

我们盼望完成一个最优容量的方法,它跟业务增长完满是婚配的方法。

这个曲线并不很难完成,只需扩容够频仍,跟这个便是完全符合的最优容量的曲线。

你发明它容量缺乏是分钟级的,扩容也是分钟级的,那你完全可以描出这么一套如出一辙的曲线出来。

运用硬件目标评价容量

我们会说你怎样晓得这个效劳的容量缺乏的?普通我们第一个反响便是用硬件目标,包罗 CPU 运用率是几多,磁盘空间几多,网卡容量、内存。这也能处理到题目,但它不克不及处理一切题目。

运用 CPU 评价容量

效劳容量 = 以后峰值/经历 CPU 下限,这是一个运用 CPU 来算效劳容量的方法。

这是一个复杂的例子,比方你如今 CPU 以后峰值 40%,你本人的经历以为这个能到达 80% 的 CPU,复杂除下便是 50% 的容量。

硬件目标能否牢靠

这工具靠谱吗?我这里画了两个表示图:

  • 有些相似右边这张图是靠谱的,容量根本上和 CPU 是坚持增长的。
  • 有些相似左边这张窄口瓶图,CPU 涨到肯定点的时分,容量就上不去。

真实案例

这是现网打流量的例子,人为把流量打上去,会发明有些效劳怎样打都是在 80%;有些怎样都是 60%,上不去。

硬件目标的范围性

硬件目标我们以为有一些范围性:

差别效劳它依赖硬件的范例,有些是被 CPU 限定,有些是被内存限定。

临界点的质量无法预测,当 CPU 靠近 80% 或许 100% 这个点的时分,我们察看到有些效劳的质量没方法预测,不波动,有些效劳可以跑到 80%,CPU 还能波动效劳很永劫间,有些一到 80%,能够有一些恳求就不前往了。

的确,线上效劳多了当前,做的事变不大可控。我们以为应该要经过压测,才干比拟精确的失掉容量的模子。

压测方法

压侧方法分两种:

  • 一种是模仿流量
  • 一种真实流量

情况也是分两种:

  • 测试情况
  • 现网情况

四种压测方法:

  • 模仿流量在测试情况打的时分,测试团队外部对证量的一些验证。这种测试方法是测试团队担任的,我们没有太到场。
  • 模仿流量打现网有点相似于全链路压测,比方淘宝在双十一常常这么干。对微信来说,我们只在过年这么干,微信过年仿佛跟淘宝双十一差未几,都是一个比拟猖獗的形态,以是我们会在过年前用模仿的流量打一下现网,这个不是一个很罕见的压测方法。
  • 真实流量往测试情况打,普通是我们要验证一些存储功能时会这么干,把线上的流量旁路打到测试情况外面,看一下这些存储功能的状况,可以在测试情况里比拟好的模仿出来,不会影响到现网。
  • 真实流量打现网情况,我这里次要想说的,我们真的在现网压测,用真实的流量打现网情况是什么情况。

现网压测

现网压测完成起来十分复杂,当你名字效劳这块完成比拟规范的话,都是一致的流程,便是压侧流程,不绝的调此中一个效劳的权重,察看它是什么结果就行了。

现网压测能够招致的非常

如许压有什么题目,各人都能想到,你压谁人效劳,什么时分停,怎样能包管不要搞失事来。

我们以为这里有以下三点比拟要害:

  • 压测会不会引发毛病,你能不克不及实时发明。
  • 压测有没有能够带来一些底层的题目,实在你的监控是发明不了的。
  • 真的出毛病当前,你怎样能疾速规复。

效劳的自我维护

你的各个效劳有没有做好自我维护。我们引入了一个疾速回绝的观点,这个效劳正常的时分,能够你的上线每分钟 100 万个恳求也是能正常效劳的。

下游效劳给你 500 万的时分,你只能处置 100 万,你能不克不及把其他 400 万个恳求回绝失,这是我们框架完成的才能。

下游效劳的重试维护

下游效劳重试维护是怎样样的?比方你在压此中一个实例的时分,你不断加大它的权重,招致它疾速回绝前往失败了,那你有没有一个机制走到其他的实例把整个流程跑完,这也是一个比拟要害的点,这个我们也是在框架里支持了。

平面化监控

监控体系够不敷美满,包罗硬件的监控,方才提到疾速回绝的监控,另有前端跟后端这种耗时的监控,另有方才提到的后面这种,有没有发作失败,整条线都是我们需求存眷的。

可以这么说,有了效劳的自我维护、下游效劳的重试维护、平面化监控,我们才敢压测,假如这三个点搞不定,压测这个事变做不了。

秒级监控

能不克不及快的发明你的非常?为了这个题目,我们把分钟级的监控晋级成了秒级的监控,一切的非常差未几都是 10 秒钟之内就能发明。

整个完成的方法各人应该都差未几,每台机都有个收罗的,之前是每分钟上报一次到行列步队,然后再汇总,然后再入库。

如今我们改了这个逻辑,6 秒钟做一次收罗,然后数据转化,然后做一个秒级数据的汇总。下面照旧分钟级的。

放量速率静态控制

这里另有一个速率的静态控制,这里比拟庞大,不晓得怎样表明这种状况。

右边这张图是我们比拟晚期压测的完成方法,它从一个点开端,能够用一个比拟疾速的调解它权重的方法,直到挪用失败出来了,然后再回退,再持续往上压,不绝往上不往下,用这种方法来靠近你的容量下限。

这个点各人很分明看到一个题目,运维在压测的时分实在是给本人找事,每次压测都打下去,又失下去,打下去。

失败曲线就像狗啃的一样,不断有抖来抖去的曲线。这种压测方法,运维本人都受不了。

前面我们调了一下,实在这个也跟我们效劳框架提供的才能相干,我们整个效劳框架会有一个入队/出队的机制,每个微效劳自身都市有如许的机制。

这里行列步队的积存状况是比拟要害的目标,我们会监控入队耽误,它出队,发明它一有积存,功能曾经跟不上了,我们经过这种目标来调解压测的速率,大约完成的结果是左边这张图。

后期是比拟快的权重,当察看到行列步队曾经有积存有耽误,就开端放缓,不断到达一个点,能够最初谁人点是有一点点压测失败,完成这么一个结果,整个进程中能够只要几秒钟,就失掉功能模子,失掉压测真实的值。

现网压测结果

这是我们真实的线上紧缩的后果。这张图打出来的斜率是先涨得比拟快,前期再渐渐增长,然后把这个压测点停失了。

为了打出这张图的结果,我们还搞了蛮久的,能够大约一年多才到达这种近况,根本上不会给现网效劳带来失败的。

容量办理小结

这个事变我们做完了,以为有几方面的收益:

  • 效劳的资源需求可精确量化,方才提到几百微效劳,每个是怎样算出来的。
  • 可确认效劳的最优机型,怎样晓得你这个微效劳合适于哪种机型?有些效劳依据我们压测会发明它有些场景跟他人纷歧样,我们只需把主动化压测的方法完成了,每个模子试一下,压出来你晓得它最优的机型是怎样样的。

主动调理

业务增长的主动扩容

处理业务增长的主动扩容,由于你的业务量在涨,你的用户的恳求包罗种种恳求量都是随着目标在涨的。

你晓得业务量怎样增长,晓得微效劳的增长曲线,后面的压测又晓得每个实例的功能怎样样,你就可以精确晓得我如今容量大约比例是在哪条线上。

我们普通让它跑在 50%、60% 这个区间内,66% 是一个容灾的预留,我们先摆设三个 IDC 外面,你要想挂失两个,别的一个也不会有什么非常的话,能够便是这两个限。

我们会留出一些工夫给推销呆板给我们,会把一些效劳的流量控制在50%这个点。

非常状况的主动扩容

另有一些非常的状况:

  • 业务量的突增,这种是某些产物搞运动没有告诉我们,我们会用一些粗犷的方法来处理,包罗说 CPU,我们会给它定一个点,当你的 CPU 冲过这个点的时分,我们会主动提倡扩容。
  • 顺序功能降落,你业务没有太大有变革,但你顺序变了,这实在也会招致容量不 ok。这个点我们是可以监测到这种状况的,就看我们压测的频率有多频仍,假如你每天都压测,你可以把压测的曲线描出来。

顺序功能降落的公道性评价

我们差未几有些效劳是 2015 年每天都在压,每一天他的功能是怎样样的,我们描出一条曲线出来。

能够会发明有一些工夫点功能降落比拟远,比方这里的例子是他发了个大版本,特性外面添加了一些处置逻辑,以是功能降落比拟分明。

这个事变能够过了一两个月当前,有些同事出来处理 fix 它,这种功能监控我以为是后面的容量办理和智能交互这一块的副产物,这个副产物我们用得还比拟多的,可以精确晓得整个微效劳功能变革怎样样。

功能办理闭环

能不克不及不要让它呈现这种新的降落的点,我们每天都在压,能不克不及再快一点,间接在它上线的时分间接拦住。

比方说开辟同窗灰度上了一个台机,我们立刻压测它灰度上线的这个呆板,看它的功能怎样样,假如发明它的功能降落,就把他拉住。

几种业务形状

这是我们现网的一些业务形状,能够比拟多的便是最下面这种图,它在早晨 9 点到 10 点迎来它的最顶峰。两头这种图普通跟任务相干的如微信,任务工夫段用得比拟多的。

另有一种是最底下这种,比拟典范的例子是微信运动,微信运动仿佛是早晨 22 点的时分会来一步。

另有一些比拟陈旧的业务,漂泊瓶,用得脑残粉还挺多的,他们会守着 0 点的时分。

削峰填谷

我们对这些业务曲线盼望做什么?

  • 峰那么高,我们一切的设置装备摆设都是为了应付最高的谁人峰,这个峰能不克不及做点特别处置,不给它们风险设置装备摆设。
  • 早晨零点当前,这么低的业务量,设置装备摆设挺糜费的。我们盼望有一个削峰填谷的作用,原理照旧很复杂,便是把你的有些效劳跟别的一些效劳的峰值错开。有些效劳顶峰期过了,把它的资源保持出来,至于谁去用它不论。

在线业务削峰

在线业务削峰:

  • 惯例效劳,顶峰期后开释资源。
  • 错峰效劳,获取资源。

离线盘算填谷

离线盘算填谷:

  • 离线义务的运转时段

01:00 ~ 08:00 不限义务

08:00 ~ 20:00 义务入队控制

  • 离线义务的资源占用

cpu.shares + memory.limit_in_bytes + blkio

离线义务的优先级最低

离线盘算,清晨那段工夫的确都很闲。这个时分比拟合适离线盘算来调理,微信群之前离线盘算的工具比拟少,次要是语音输出等一些人工智能方面的工具。

近来能够有一些看一看、搜一搜的新功用,他们用的离线盘算的调理还挺多的。

资源占用方面,这几个场合的设置装备摆设根本上是 Cgroup 控制得比拟严厉一些。然后把离线义务的优先级调一下,用离线义务来把我们低峰的谷填平了。

主动调理小结

这在主动调理这块是我们完成的一个目的:

  • 通盘控制一切的在线效劳,充沛应用资源。
  • 离线义务这块不必独自请求盘算资源,间接用我们在线上的一些 CPU 内存就好,存储独自去说。

吴磊,微信根底平台运维担任人,2010 年参加 QQ 邮箱运维团队,从微信第一个版本开端全程支持从 0 到数亿同时在线的蛮横生长。现在担任音讯收发、冤家圈等根底业务运维,专注主动化运维零碎建立。

【编辑引荐】

  1. 通博8888官网运维之ntpdate同步网络工夫
  2. 美团外卖:日订单量超越1600万的主动化业务运维之路
  3. 六团体怎样运维一万台效劳器?
  4. 从美团顺序员的劫难,看美团外卖主动化运维体系建立
  5. IT运维的救赎:顺丰运维的抱负践行
  6. 冲破1300多个使用运维主动化的技能藩篱!
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
各人都在看
猜你喜好

读 书 +更多

框架设计(第2版)CLR Via C#

作为深受编程职员敬爱和尊崇的编程专家,微软.NET开辟团队的参谋,本书作者Jeffrey Richter针对开辟种种使用顺序(如Web Form、通博8888 For...

订阅51CTO邮刊

点击这里检查样刊

订阅51CTO邮刊