今天的主題主要是關(guān)于彈性伸縮、擴(kuò)容和縮容這些方面。

[[214411]]

微信業(yè)務(wù)量增長(zhǎng)的時(shí)候，我們比較關(guān)心的是效率問(wèn)題。前期可能兩三個(gè)月就漲了 1 倍的量，怎么能夠保證我們的運(yùn)營(yíng)效率是跟得上的？后期主要關(guān)心的是成本問(wèn)題。

我們?cè)?2014 年以后增長(zhǎng)有點(diǎn)放緩，所以主要的精力會(huì)在成本這個(gè)方面。

如上圖，下面我主要分為四個(gè)方面來(lái)做分享：

• 運(yùn)營(yíng)規(guī)范。
• 云化管理。
• 容量管理。
• 自動(dòng)調(diào)度。

運(yùn)營(yíng)規(guī)范

配置文件規(guī)范

先來(lái)看配置文件規(guī)范，我們前期花了比較多的精力?？赡苷麄€(gè)系統(tǒng)設(shè)計(jì)比較復(fù)雜，最開始都會(huì)有一些配置管理工程師專門來(lái)處理，后期我們把這塊搞得比較規(guī)范了。

配置文件規(guī)范分為下面幾項(xiàng)：

目錄結(jié)構(gòu)標(biāo)準(zhǔn)

這就是一個(gè)服務(wù)部署上線的時(shí)候怎么定義它的目錄結(jié)構(gòu)，大家應(yīng)該先做好這些目錄結(jié)構(gòu)標(biāo)準(zhǔn)的定義。

跨服務(wù)的相同配置項(xiàng)管理

為什么提這一點(diǎn)？可能有些配置項(xiàng)你會(huì)在這個(gè)服務(wù)里需要這幾個(gè)配置項(xiàng)，在另一個(gè)服務(wù)里也需要這幾個(gè)配置項(xiàng)。

如果更改這個(gè)配置項(xiàng)的時(shí)候，你是不是把服務(wù) A 發(fā)一遍，服務(wù) B 也發(fā)一遍？我們有一套機(jī)制，每臺(tái)機(jī)每個(gè)目錄下都會(huì)有一個(gè)全局共用的配置項(xiàng)，我們會(huì)通過(guò)一些自動(dòng)化的灰度的方式來(lái)控制這里的發(fā)布，這一塊是單獨(dú)拎出來(lái)的。

同一服務(wù)內(nèi)不同實(shí)例的差異配置項(xiàng)管理

不確定大家運(yùn)營(yíng)時(shí)會(huì)不會(huì)碰到類似的問(wèn)題，就算你用 Docker 了你鏡像管理挺好的。

你部署個(gè)實(shí)例出來(lái)，可能你們的業(yè)務(wù)就需要在實(shí)例 1 上做一些調(diào)整，當(dāng)然你也可以用腳本來(lái)管理。

但是我們覺(jué)得這是比較復(fù)雜的狀態(tài)，我們會(huì)把這些差異性全部給它統(tǒng)一抽取出來(lái)，盡量做到所有的環(huán)境下它的配置文件的 MD5 都是一致的。

開發(fā)/測(cè)試/現(xiàn)網(wǎng)的差異配置項(xiàng)管理

前期也會(huì)有這個(gè)問(wèn)題，開發(fā)環(huán)境我們一般不管，測(cè)試環(huán)境也是運(yùn)維來(lái)負(fù)責(zé)管理，現(xiàn)網(wǎng)當(dāng)然是運(yùn)維管理的。

基本上測(cè)試和現(xiàn)網(wǎng)的差異只有路由的差異，其他的配置項(xiàng)我們都保證它是完全一致的。

做這么一個(gè)要求，大概實(shí)現(xiàn)的效果是不管你通過(guò)什么手段擴(kuò)容，我們直接一個(gè)鏡像打過(guò)去或者直接一個(gè)包拷過(guò)去就可以了，不會(huì)再有后續(xù)的腳本來(lái)改動(dòng)它。

同一服務(wù)下同一版本的多個(gè)實(shí)例，在所有環(huán)境下配置文件的 MD5 都嚴(yán)格一致。

名字服務(wù)規(guī)范

名字服務(wù)這塊比較重要，分為三層：

• 接入層，類 LVS 實(shí)現(xiàn)。
• 邏輯層，類 etcd 實(shí)現(xiàn)。
• 存儲(chǔ)層，路由配置自動(dòng)化。

服務(wù)伸縮是運(yùn)維工程，獨(dú)立于研發(fā)的變更發(fā)布。

接入層和邏輯層，都是類似的實(shí)現(xiàn)，我們內(nèi)部根據(jù)我們的業(yè)務(wù)特性做了一些業(yè)務(wù)開發(fā)。

存儲(chǔ)層跟 QQ 有點(diǎn)不一樣，QQ 好像是邏輯層和存儲(chǔ)層都是用同一個(gè)名字服務(wù)實(shí)現(xiàn)，我們?cè)诖鎯?chǔ)層這里還沒(méi)有做這方面的配置。

我們現(xiàn)在存儲(chǔ)層跟邏輯層隔得比較開，在涉及到數(shù)據(jù)的方面，我們差不多可以認(rèn)為是運(yùn)維能夠配置的方式，但是又不完全是能夠配置，用那些輔助腳本來(lái)配置。

服務(wù)伸縮是運(yùn)維工程，我們不希望在服務(wù)伸縮時(shí)還考慮別的因素，獨(dú)立于研發(fā)的變更發(fā)布。

我們有個(gè)特點(diǎn)，研發(fā)是通過(guò)運(yùn)維提供的變更系統(tǒng)，他在上面基本上不需要做什么操作，整條鏈就打通了，運(yùn)維不用關(guān)心變更發(fā)布，只需要管好服務(wù)伸縮就好。

數(shù)據(jù)存儲(chǔ)規(guī)范

數(shù)據(jù)存儲(chǔ)規(guī)范如下：

• 接入層，不帶數(shù)據(jù)。
• 邏輯層，帶短周期 cache、帶靜態(tài)數(shù)據(jù)、禁止動(dòng)態(tài)數(shù)據(jù)落地。
• 存儲(chǔ)層，帶長(zhǎng)周期 cache、基于 paxos 協(xié)議的數(shù)據(jù)落地。

接入層和邏輯層的服務(wù)伸縮，無(wú)需考慮數(shù)據(jù)遷移和 cache 命中率。

數(shù)據(jù)存儲(chǔ)方面，單獨(dú)拎一頁(yè)出來(lái)會(huì)覺(jué)得這個(gè)場(chǎng)景是比較多人中招的，比如接入層肯定不會(huì)帶什么數(shù)據(jù)的，邏輯層我希望它是不帶數(shù)據(jù)的，而且我們也嚴(yán)格要求不帶數(shù)據(jù)的。

經(jīng)常出現(xiàn)這樣的場(chǎng)景，他的邏輯層要自動(dòng)伸縮，跑了一段時(shí)間上線了一些邏輯在上面保存了一些數(shù)據(jù)，在下面做縮容的時(shí)候是不是就中招了，會(huì)有這個(gè)問(wèn)題，所以我們會(huì)定這個(gè)規(guī)范。

邏輯層是不帶數(shù)據(jù)的，會(huì)有靜態(tài)數(shù)據(jù)，包括用戶發(fā)的消息、用戶發(fā)的朋友圈，很明顯應(yīng)該放到存儲(chǔ)層的。

接入層不帶數(shù)據(jù)，其實(shí)歷史上我們也有一次是帶了數(shù)據(jù)的，在每次過(guò)年搶紅包的時(shí)候，所有人都在搖的那一把，那個(gè)量是非?？植赖?。

搖紅包那個(gè)點(diǎn)我們做設(shè)計(jì)是每個(gè)搖紅包的請(qǐng)求真的打到我們接入層，不會(huì)有客戶端搖五次才有一次請(qǐng)求上來(lái)。

我們的接入層的性能保證我們能抗住這個(gè)量，但是后面的邏輯層肯定撐不了這個(gè)量，1 秒鐘幾千萬(wàn)。

這個(gè)時(shí)候我們會(huì)做一些很特殊的邏輯，在接入層直接帶上紅包數(shù)據(jù)，當(dāng)然這是比較特殊的場(chǎng)景，我們只在過(guò)年的時(shí)候這個(gè)規(guī)范是沒(méi)有執(zhí)行的。

運(yùn)營(yíng)規(guī)范小結(jié)

運(yùn)營(yíng)規(guī)范小結(jié)：

• 階段目標(biāo)

服務(wù)可運(yùn)維

• 落實(shí)措施

變更系統(tǒng)攔截

全網(wǎng)掃描不規(guī)范的服務(wù)

這里說(shuō)了幾點(diǎn)，我們的目標(biāo)簡(jiǎn)單來(lái)說(shuō)就是服務(wù)可運(yùn)維，可運(yùn)維的意思就是你做擴(kuò)容縮容的時(shí)候不需要做人工的操作，如果做人工的操作就是不可運(yùn)維。

為了實(shí)現(xiàn)服務(wù)可運(yùn)維，我們?cè)谧兏到y(tǒng)里做了一些攔截，它接下來(lái)變更可能不符合我們運(yùn)營(yíng)規(guī)范或者之前有不符合我們運(yùn)營(yíng)規(guī)范的地方，我們都會(huì)攔下來(lái)，要求變更，實(shí)現(xiàn)我們的運(yùn)維規(guī)范。

云化管理

接下來(lái)說(shuō)一下云，大家用云也挺多的，近幾年也比較火，可能大家用得比較多的是 Docker，微信這邊我們沒(méi)有用 Docker，后面也會(huì)說(shuō)到為什么沒(méi)有用的原因。

為什么上云

上云的兩點(diǎn)原因：

微服務(wù)總數(shù)近 5k。

同物理機(jī)上多服務(wù)的資源搶占問(wèn)題。

先說(shuō)為什么要上云，在 2013 年、2014 年時(shí)，我們的微服務(wù)已經(jīng)到差不多 5000 個(gè)。

我是近幾年才知道這個(gè)叫微服務(wù)，我們之前實(shí)現(xiàn)方式已經(jīng)是好多年都算微服務(wù)的方式了。

最開始說(shuō)微服務(wù)這個(gè)事情的時(shí)候，我記得是 QQ 那邊海量運(yùn)營(yíng)的一些課程都會(huì)提到，我覺(jué)得這個(gè)思路跟微服務(wù)是完全一致的。

我們運(yùn)維這邊在實(shí)現(xiàn)了一套新服務(wù)發(fā)布的時(shí)候，基本上不會(huì)給研發(fā)有什么限制說(shuō)你這個(gè)服務(wù)不要搞太多。

所以整個(gè)系統(tǒng)搞下來(lái)那個(gè)量是比較夸張的，當(dāng)然就會(huì)出現(xiàn)他的多個(gè)服務(wù)要在同一臺(tái)機(jī)上部署，因?yàn)槔锩嬗?5000 個(gè)微服務(wù)，一定要同物理機(jī)部署。部署多個(gè)服務(wù)就會(huì)有資源搶占，基于這個(gè)因素，我們就上云。

哪部分上云

哪部分上云：

• 接入層，獨(dú)占物理機(jī)、 容量充足、 變更少。
• 邏輯層，混合部署、 容量不可控、變更頻繁。
• 存儲(chǔ)層，獨(dú)占物理機(jī)、容量可控、變更少。

哪一塊上云，剛才也說(shuō)到，接入層因?yàn)橐缸”容^猛的量，微信的用戶也比較多，如果它有什么問(wèn)題，可能接入層會(huì)雪崩。

所以我們主要是獨(dú)占物理機(jī)，容量足，變更也少，暫時(shí)沒(méi)有上云的需求。

在邏輯層這里，之前提到 5000 多個(gè)微服務(wù)，所以比較混亂，變更比較多，容量也不可控，所以這塊上了云。

存儲(chǔ)層這里，也沒(méi)有上云，但是有單獨(dú)的容量管理和數(shù)據(jù)遷移。

基于 Cgroup 的云化

基于 Cgroup 的云化：

• 虛擬機(jī)型定制

VC11 = 1 個(gè) cpu 核 + 1G 內(nèi)存

VC24 = 2 個(gè) cpu 核 + 4G 內(nèi)存

• 物理機(jī)分片

我們?cè)频姆绞绞侵苯?Cgroup，Cgroup 這個(gè)名字可能有些人不知道，我們用的是內(nèi)核 Cgroup 這種機(jī)制。

在現(xiàn)網(wǎng)的時(shí)候，用類似簡(jiǎn)單的虛擬機(jī)型定制，比如 1 個(gè) cpu+1G 內(nèi)存。

前期我們也有一些流量因素的考慮，后來(lái)把它給取消掉了，我們系統(tǒng)架構(gòu)上保證的那個(gè)流量好像是不怎么會(huì)成為問(wèn)題的。

這里簡(jiǎn)單列了一下虛擬機(jī)分片的方式，怎么隔的方式都有，我們隔的這么隨意也帶來(lái)另外一個(gè)問(wèn)題，系統(tǒng)運(yùn)轉(zhuǎn)過(guò)程中會(huì)有一些類似于磁盤碎片的東西存在，就好像你 Windows 跑了很久以后也會(huì)有磁盤碎片存在一樣。

這個(gè)我們也有一些比較特殊的方法來(lái)處理。

線上未啟用 Docker

我們沒(méi)有用 Docker 的幾點(diǎn)原因：

• svrkit 框架 100% 覆蓋全網(wǎng)，已實(shí)現(xiàn)標(biāo)準(zhǔn)化規(guī)范化。
• 框架本身大量依賴 IPC 交互。
• 自研非侵入式 vs Docker 侵入式。

Docker 太火了，我們差不多在 2014 年、2015 年的時(shí)候，線上也少量上線了一輪。

我們這個(gè) svrkit 框架是我們微信內(nèi)部自研的一套框架，100% 覆蓋全網(wǎng)。

100% 什么意思？一點(diǎn)開源代碼都沒(méi)有，包括前面大家可能用得最多的 Nginx 做接入，這個(gè)我們也是在自研上切換的，包括后面的存儲(chǔ)，前期用了 MySQL，后期也都換成自己的組件了。

現(xiàn)網(wǎng)用我們自己的框架 100% 覆蓋了，我們的標(biāo)準(zhǔn)化和規(guī)范化都是比較好的。

可以說(shuō)Docker解決的一些問(wèn)題在我們這里不是問(wèn)題：

• 我們對(duì) Docker 的需求不是很強(qiáng)烈。
• 框架本身我們用了很多 IPC 交互，這些東西在 Docker 里都做了很嚴(yán)格的規(guī)范，如果我們用 Docker，可能會(huì)把這些 Docker 里的各種機(jī)制破壞掉。如果是這種情況，還不如不用 Docker。
• 我們對(duì) Docker 這種接入方式的實(shí)現(xiàn)還是有顧慮，早一兩年有人跟我討論比較多，Docker 主進(jìn)程起來(lái)的時(shí)候，可能由于要更新 Docker 本身，會(huì)導(dǎo)致服務(wù)重啟。

好像近期已經(jīng)解決這個(gè)問(wèn)題，這個(gè)在早期來(lái)看我們認(rèn)為是一個(gè)比較嚴(yán)重的問(wèn)題，我不希望說(shuō)因?yàn)?Docker 本身的變更，對(duì)線上的服務(wù)有任何影響。

私有云調(diào)度系統(tǒng)

基于上面的點(diǎn)，我們自研了一套云化管理的 Docker 系統(tǒng)。

上圖是我們私有云調(diào)度系統(tǒng)：

• 基于 svrkit 框架自研。
• 參考 borg/yarn/k8s/mesos 等主流調(diào)度系統(tǒng)的優(yōu)點(diǎn)。
• 覆蓋 80% 的微服務(wù)。

基于我前面提到的 svrkit 框架+自研，調(diào)度系統(tǒng)當(dāng)然也要用我們自己的調(diào)度系統(tǒng)覆蓋，目前覆蓋了 80% 的微服務(wù)，還差一點(diǎn)點(diǎn) 100% 覆蓋。

私有云調(diào)度系統(tǒng)架構(gòu)

這是我們的架構(gòu)，熟悉的人一看就知道跟業(yè)界的事情沒(méi)有什么區(qū)別，中間有一些虛擬化的坑，可以認(rèn)為跟大家用得沒(méi)有太大區(qū)別，不細(xì)講了。

云化管理小結(jié)

云化管理小結(jié)：

• 階段目標(biāo)

服務(wù)間資源隔離

服務(wù)伸縮頁(yè)面化操作

• 落實(shí)措施

部署系統(tǒng)攔截未上云業(yè)務(wù)

主動(dòng)改造核心業(yè)務(wù)

在云化管理這一塊，我們實(shí)現(xiàn)的一個(gè)目標(biāo)就是資源隔離，Docker 服務(wù)之間不要因?yàn)橐粋€(gè)服務(wù)異常搞的第二個(gè)服務(wù)也異常。

第二是服務(wù)伸縮頁(yè)面化操作，有些服務(wù)還是很龐大的，一個(gè)服務(wù)下幾千上萬(wàn)臺(tái)都可能，這種時(shí)候不希望你上機(jī)器的，在頁(yè)面上點(diǎn)就可以了。

我們?yōu)榱寺鋵?shí)這個(gè)目標(biāo)，會(huì)把部署系統(tǒng)，把那些沒(méi)有上云的攔住，他要走舊的部署方式上線，他需要走舊的流程才能走舊的商業(yè)模式。

前面這些運(yùn)營(yíng)規(guī)范和云化管理，相信大家多多少少都會(huì)有自己的實(shí)現(xiàn)方式，也都會(huì)有自己的一些總結(jié)。后面容量這塊不確定大家都是怎么改的。

容量管理

如何支撐業(yè)務(wù)發(fā)展

這是一個(gè)業(yè)務(wù)量增長(zhǎng)的曲線，也是我們?nèi)萘康那€。

一般來(lái)說(shuō)你擴(kuò)了一次容就一直平衡在這里，有一個(gè)點(diǎn)你發(fā)現(xiàn)撐不住了，要擴(kuò)容，擴(kuò)上去，就一直保持這個(gè)狀態(tài)，跟容量曲線是不怎么匹配的。

第一個(gè)點(diǎn)是你這個(gè)容量低于現(xiàn)網(wǎng)的業(yè)務(wù)量的時(shí)候，這其實(shí)是容量不足的，能不能很快發(fā)現(xiàn)這個(gè)問(wèn)題。

第二個(gè)點(diǎn)是處理效率，容量不足的時(shí)候把曲線打上去，擴(kuò)容需要多長(zhǎng)時(shí)間，如果是幾天或者幾分鐘，這個(gè)效率是不一樣的。

我們希望實(shí)現(xiàn)一個(gè)最優(yōu)容量的方式，它跟業(yè)務(wù)增長(zhǎng)完全是匹配的方式。

這個(gè)曲線并不很難實(shí)現(xiàn)，只要擴(kuò)容夠頻繁，跟這個(gè)就是完全吻合的最優(yōu)容量的曲線。

你發(fā)現(xiàn)它容量不足是分鐘級(jí)的，擴(kuò)容也是分鐘級(jí)的，那你完全可以描出這么一套一模一樣的曲線出來(lái)。

使用硬件指標(biāo)評(píng)估容量

我們會(huì)說(shuō)你怎么知道這個(gè)服務(wù)的容量不足的？一般我們第一個(gè)反應(yīng)就是用硬件指標(biāo)，包括 CPU 使用率是多少，磁盤空間多少，網(wǎng)卡容量、內(nèi)存。這也能解決到問(wèn)題，但它不能解決所有問(wèn)題。

使用 CPU 評(píng)估容量

服務(wù)容量 = 當(dāng)前峰值/經(jīng)驗(yàn) CPU 上限，這是一個(gè)使用 CPU 來(lái)算服務(wù)容量的方式。

這是一個(gè)簡(jiǎn)單的例子，比如你現(xiàn)在 CPU 當(dāng)前峰值 40%，你自己的經(jīng)驗(yàn)覺(jué)得這個(gè)能達(dá)到 80% 的 CPU，簡(jiǎn)單除下就是 50% 的容量。

硬件指標(biāo)是否可靠

這東西靠譜嗎？我這里畫了兩個(gè)示意圖：

• 有些類似左邊這張圖是靠譜的，容量基本上和 CPU 是保持增長(zhǎng)的。
• 有些類似右邊這張窄口瓶圖，CPU 漲到一定點(diǎn)的時(shí)候，容量就上不去。

真實(shí)案例

這是現(xiàn)網(wǎng)打流量的例子，人為把流量打上去，會(huì)發(fā)現(xiàn)有些服務(wù)怎么打都是在 80%；有些怎么都是 60%，上不去。

硬件指標(biāo)的局限性

硬件指標(biāo)我們認(rèn)為有一些局限性：

不同服務(wù)它依賴硬件的類型，有些是被 CPU 限制，有些是被內(nèi)存限制。

臨界點(diǎn)的質(zhì)量無(wú)法預(yù)測(cè)，當(dāng) CPU 接近 80% 或者 100% 這個(gè)點(diǎn)的時(shí)候，我們觀察到有些服務(wù)的質(zhì)量沒(méi)辦法預(yù)測(cè)，不穩(wěn)定，有些服務(wù)能夠跑到 80%，CPU 還能穩(wěn)定服務(wù)很長(zhǎng)時(shí)間，有些一到 80%，可能有一些請(qǐng)求就不返回了。

確實(shí)，線上服務(wù)多了以后，做的事情不大可控。我們覺(jué)得應(yīng)該要通過(guò)壓測(cè)，才能比較準(zhǔn)確的得到容量的模型。

壓測(cè)方式

壓側(cè)方式分兩種：

• 一種是模擬流量
• 一種真實(shí)流量

環(huán)境也是分兩種：

• 測(cè)試環(huán)境
• 現(xiàn)網(wǎng)環(huán)境

四種壓測(cè)方式：

• 模擬流量在測(cè)試環(huán)境打的時(shí)候，測(cè)試團(tuán)隊(duì)內(nèi)部對(duì)質(zhì)量的一些驗(yàn)證。這種測(cè)試方式是測(cè)試團(tuán)隊(duì)負(fù)責(zé)的，我們沒(méi)有太參與。
• 模擬流量打現(xiàn)網(wǎng)有點(diǎn)類似于全鏈路壓測(cè)，比如淘寶在雙十一經(jīng)常這么干。對(duì)微信來(lái)說(shuō)，我們只在過(guò)年這么干，微信過(guò)年好像跟淘寶雙十一差不多，都是一個(gè)比較瘋狂的狀態(tài)，所以我們會(huì)在過(guò)年前用模擬的流量打一下現(xiàn)網(wǎng)，這個(gè)不是一個(gè)很常見的壓測(cè)方式。
• 真實(shí)流量往測(cè)試環(huán)境打，一般是我們要驗(yàn)證一些存儲(chǔ)性能時(shí)會(huì)這么干，把線上的流量旁路打到測(cè)試環(huán)境里面，看一下這些存儲(chǔ)性能的情況，可以在測(cè)試環(huán)境里比較好的模擬出來(lái)，不會(huì)影響到現(xiàn)網(wǎng)。
• 真實(shí)流量打現(xiàn)網(wǎng)環(huán)境，我這里主要想說(shuō)的，我們真的在現(xiàn)網(wǎng)壓測(cè)，用真實(shí)的流量打現(xiàn)網(wǎng)環(huán)境是什么狀況。

現(xiàn)網(wǎng)壓測(cè)

現(xiàn)網(wǎng)壓測(cè)實(shí)現(xiàn)起來(lái)非常簡(jiǎn)單，當(dāng)你名字服務(wù)這塊實(shí)現(xiàn)比較標(biāo)準(zhǔn)的話，都是統(tǒng)一的流程，就是壓側(cè)流程，不停的調(diào)其中一個(gè)服務(wù)的權(quán)重，觀察它是什么后果就行了。

現(xiàn)網(wǎng)壓測(cè)可能導(dǎo)致的異常

這樣壓有什么問(wèn)題，大家都能想到，你壓那個(gè)服務(wù)，什么時(shí)候停，怎么能保證不要搞出事來(lái)。

我們認(rèn)為這里有以下三點(diǎn)比較關(guān)鍵：

• 壓測(cè)會(huì)不會(huì)引發(fā)故障，你能不能及時(shí)發(fā)現(xiàn)。
• 壓測(cè)有沒(méi)有可能帶來(lái)一些底層的問(wèn)題，其實(shí)你的監(jiān)控是發(fā)現(xiàn)不了的。
• 真的出故障以后，你怎么能快速恢復(fù)。

服務(wù)的自我保護(hù)

你的各個(gè)服務(wù)有沒(méi)有做好自我保護(hù)。我們引入了一個(gè)快速拒絕的概念，這個(gè)服務(wù)正常的時(shí)候，可能你的上線每分鐘 100 萬(wàn)個(gè)請(qǐng)求也是能正常服務(wù)的。

上游服務(wù)給你 500 萬(wàn)的時(shí)候，你只能處理 100 萬(wàn)，你能不能把其他 400 萬(wàn)個(gè)請(qǐng)求拒絕掉，這是我們框架實(shí)現(xiàn)的能力。

上游服務(wù)的重試保護(hù)

上游服務(wù)重試保護(hù)是怎么樣的？比如你在壓其中一個(gè)實(shí)例的時(shí)候，你一直加大它的權(quán)重，導(dǎo)致它快速拒絕返回失敗了，那你有沒(méi)有一個(gè)機(jī)制走到其他的實(shí)例把整個(gè)流程跑完，這也是一個(gè)比較關(guān)鍵的點(diǎn)，這個(gè)我們也是在框架里支持了。

立體化監(jiān)控

監(jiān)控體系夠不夠完善，包括硬件的監(jiān)控，剛才提到快速拒絕的監(jiān)控，還有前端跟后端這種耗時(shí)的監(jiān)控，還有剛才提到的前面這種，有沒(méi)有發(fā)生失敗，整條線都是我們需要關(guān)注的。

可以這么說(shuō)，有了服務(wù)的自我保護(hù)、上游服務(wù)的重試保護(hù)、立體化監(jiān)控，我們才敢壓測(cè)，如果這三個(gè)點(diǎn)搞不定，壓測(cè)這個(gè)事情做不了。

秒級(jí)監(jiān)控

能不能快的發(fā)現(xiàn)你的異常？為了這個(gè)問(wèn)題，我們把分鐘級(jí)的監(jiān)控升級(jí)成了秒級(jí)的監(jiān)控，所有的異常差不多都是 10 秒鐘之內(nèi)就能發(fā)現(xiàn)。

整個(gè)實(shí)現(xiàn)的方式大家應(yīng)該都差不多，每臺(tái)機(jī)都有個(gè)采集的，之前是每分鐘上報(bào)一次到隊(duì)列，然后再匯總，然后再入庫(kù)。

現(xiàn)在我們改了這個(gè)邏輯，6 秒鐘做一次采集，然后數(shù)據(jù)轉(zhuǎn)化，然后做一個(gè)秒級(jí)數(shù)據(jù)的匯總。上面還是分鐘級(jí)的。

放量速率動(dòng)態(tài)控制

這里還有一個(gè)速率的動(dòng)態(tài)控制，這里比較復(fù)雜，不知道怎么解釋這種情況。

左邊這張圖是我們比較早期壓測(cè)的實(shí)現(xiàn)方式，它從一個(gè)點(diǎn)開始，可能用一個(gè)比較快速的調(diào)整它權(quán)重的方式，直到調(diào)用失敗出來(lái)了，然后再回退，再繼續(xù)往上壓，不停往上不往下，用這種方式來(lái)接近你的容量上限。

這個(gè)點(diǎn)大家很明顯看到一個(gè)問(wèn)題，運(yùn)維在壓測(cè)的時(shí)候其實(shí)是給自己找事，每次壓測(cè)都打上來(lái)，又掉下去，打上來(lái)。

失敗曲線就像狗啃的一樣，一直有抖來(lái)抖去的曲線。這種壓測(cè)方式，運(yùn)維自己都受不了。

后面我們調(diào)了一下，其實(shí)這個(gè)也跟我們服務(wù)框架提供的能力相關(guān)，我們整個(gè)服務(wù)框架會(huì)有一個(gè)入隊(duì)/出隊(duì)的機(jī)制，每個(gè)微服務(wù)本身都會(huì)有這樣的機(jī)制。

這里隊(duì)列的積壓情況是比較關(guān)鍵的指標(biāo)，我們會(huì)監(jiān)控入隊(duì)延遲，它出隊(duì)，發(fā)現(xiàn)它一有積壓，性能已經(jīng)跟不上了，我們通過(guò)這種指標(biāo)來(lái)調(diào)整壓測(cè)的速率，大概實(shí)現(xiàn)的效果是右邊這張圖。

前期是比較快的權(quán)重，當(dāng)觀察到隊(duì)列已經(jīng)有積壓有延遲，就開始放緩，一直達(dá)到一個(gè)點(diǎn)，可能最后那個(gè)點(diǎn)是有一點(diǎn)點(diǎn)壓測(cè)失敗，實(shí)現(xiàn)這么一個(gè)效果，整個(gè)過(guò)程中可能只有幾秒鐘，就得到性能模型，得到壓測(cè)真實(shí)的值。

現(xiàn)網(wǎng)壓測(cè)效果

這是我們真實(shí)的線上壓縮的結(jié)果。這張圖打出來(lái)的斜率是先漲得比較快，后期再慢慢增長(zhǎng)，然后把這個(gè)壓測(cè)點(diǎn)停掉了。

為了打出這張圖的效果，我們還搞了蠻久的，可能大概一年多才達(dá)到這種現(xiàn)狀，基本上不會(huì)給現(xiàn)網(wǎng)服務(wù)帶來(lái)失敗的。

容量管理小結(jié)

這個(gè)事情我們做完了，覺(jué)得有幾方面的收益：

• 服務(wù)的資源需求可準(zhǔn)確量化，剛才提到幾百微服務(wù)，每個(gè)是怎么算出來(lái)的。
• 可確認(rèn)服務(wù)的最優(yōu)機(jī)型，怎么知道你這個(gè)微服務(wù)適合于哪種機(jī)型？有些服務(wù)根據(jù)我們壓測(cè)會(huì)發(fā)現(xiàn)它有些場(chǎng)景跟別人不一樣，我們只要把自動(dòng)化壓測(cè)的方式實(shí)現(xiàn)了，每個(gè)模型試一下，壓出來(lái)你知道它最優(yōu)的機(jī)型是怎么樣的。

自動(dòng)調(diào)度

業(yè)務(wù)增長(zhǎng)的自動(dòng)擴(kuò)容

解決業(yè)務(wù)增長(zhǎng)的自動(dòng)擴(kuò)容，因?yàn)槟愕臉I(yè)務(wù)量在漲，你的用戶的請(qǐng)求包括各種請(qǐng)求量都是跟著指標(biāo)在漲的。

你知道業(yè)務(wù)量怎么增長(zhǎng)，知道微服務(wù)的增長(zhǎng)曲線，前面的壓測(cè)又知道每個(gè)實(shí)例的性能怎么樣，你就能夠準(zhǔn)確知道我現(xiàn)在容量大概比例是在哪條線上。

我們一般讓它跑在 50%、60% 這個(gè)區(qū)間內(nèi)，66% 是一個(gè)容災(zāi)的預(yù)留，我們先部署三個(gè) IDC 里面，你要想掛掉兩個(gè)，另外一個(gè)也不會(huì)有什么異常的話，可能就是這兩個(gè)限。

我們會(huì)留出一些時(shí)間給采購(gòu)機(jī)器給我們，會(huì)把一些服務(wù)的流量控制在50%這個(gè)點(diǎn)。

異常情況的自動(dòng)擴(kuò)容

還有一些異常的情況：

• 業(yè)務(wù)量的突增，這種是某些產(chǎn)品搞活動(dòng)沒(méi)有通知我們，我們會(huì)用一些粗暴的方式來(lái)解決，包括說(shuō) CPU，我們會(huì)給它定一個(gè)點(diǎn)，當(dāng)你的 CPU 沖過(guò)這個(gè)點(diǎn)的時(shí)候，我們會(huì)自動(dòng)發(fā)起擴(kuò)容。
• 程序性能下降，你業(yè)務(wù)沒(méi)有太大有變化，但你程序變了，這其實(shí)也會(huì)導(dǎo)致容量不 ok。這個(gè)點(diǎn)我們是能夠監(jiān)測(cè)到這種情況的，就看我們壓測(cè)的頻率有多頻繁，如果你每天都?jí)簻y(cè)，你可以把壓測(cè)的曲線描出來(lái)。

程序性能下降的合理性評(píng)估

我們差不多有些服務(wù)是 2015 年每天都在壓，每一天他的性能是怎么樣的，我們描出一條曲線出來(lái)。

可能會(huì)發(fā)現(xiàn)有一些時(shí)間點(diǎn)性能下降比較遠(yuǎn)，比如這里的例子是他發(fā)了個(gè)大版本，特性里面增加了一些處理邏輯，所以性能下降比較明顯。

這個(gè)事情可能過(guò)了一兩個(gè)月以后，有些同事出來(lái)解決 fix 它，這種性能監(jiān)控我認(rèn)為是前面的容量管理和智能交互這一塊的副產(chǎn)品，這個(gè)副產(chǎn)品我們用得還比較多的，可以準(zhǔn)確知道整個(gè)微服務(wù)性能變化怎么樣。

性能管理閉環(huán)

能不能不要讓它出現(xiàn)這種新的下降的點(diǎn)，我們每天都在壓，能不能再快一點(diǎn)，直接在它上線的時(shí)候直接攔住。

比如說(shuō)開發(fā)同學(xué)灰度上了一個(gè)臺(tái)機(jī)，我們馬上壓測(cè)它灰度上線的這個(gè)機(jī)器，看它的性能怎么樣，如果發(fā)現(xiàn)它的性能下降，就把他拉住。

幾種業(yè)務(wù)形態(tài)

這是我們現(xiàn)網(wǎng)的一些業(yè)務(wù)形態(tài)，可能比較多的就是最上面這種圖，它在晚上 9 點(diǎn)到 10 點(diǎn)迎來(lái)它的最高峰。中間這種圖一般跟工作相關(guān)的如微信，工作時(shí)間段用得比較多的。

還有一種是最底下這種，比較典型的例子是微信活動(dòng)，微信活動(dòng)好像是晚上 22 點(diǎn)的時(shí)候會(huì)來(lái)一步。

還有一些比較古老的業(yè)務(wù)，漂流瓶，用得腦殘粉還挺多的，他們會(huì)守著 0 點(diǎn)的時(shí)候。

削峰填谷

我們對(duì)這些業(yè)務(wù)曲線希望做什么？

• 峰那么高，我們所有的設(shè)備都是為了應(yīng)付最高的那個(gè)峰，這個(gè)峰能不能做點(diǎn)特殊處理，不給它們危險(xiǎn)設(shè)備。
• 晚上零點(diǎn)以后，這么低的業(yè)務(wù)量，設(shè)備挺浪費(fèi)的。我們希望有一個(gè)削峰填谷的作用，原理還是很簡(jiǎn)單，就是把你的有些服務(wù)跟另外一些服務(wù)的峰值錯(cuò)開。有些服務(wù)高峰期過(guò)了，把它的資源放棄出來(lái)，至于誰(shuí)去用它不管。

在線業(yè)務(wù)削峰

在線業(yè)務(wù)削峰：

• 常規(guī)服務(wù)，高峰期后釋放資源。
• 錯(cuò)峰服務(wù)，獲取資源。

離線計(jì)算填谷

離線計(jì)算填谷：

• 離線任務(wù)的運(yùn)行時(shí)段

01:00 ~ 08:00 不限任務(wù)

08:00 ~ 20:00 任務(wù)入隊(duì)控制

• 離線任務(wù)的資源占用

cpu.shares + memory.limit_in_bytes + blkio

離線任務(wù)的優(yōu)先級(jí)最低

離線計(jì)算，凌晨那段時(shí)間確實(shí)都很閑。這個(gè)時(shí)候比較適合離線計(jì)算來(lái)調(diào)度，微信群之前離線計(jì)算的東西比較少，主要是語(yǔ)音輸入等一些人工智能方面的東西。

最近可能有一些看一看、搜一搜的新功能，他們用的離線計(jì)算的調(diào)度還挺多的。

資源占用方面，這幾個(gè)場(chǎng)所的配置基本上是 Cgroup 控制得比較嚴(yán)格一些。然后把離線任務(wù)的優(yōu)先級(jí)調(diào)一下，用離線任務(wù)來(lái)把我們低峰的谷填平了。

自動(dòng)調(diào)度小結(jié)

這在自動(dòng)調(diào)度這塊是我們實(shí)現(xiàn)的一個(gè)目標(biāo)：

• 全盤控制所有的在線服務(wù)，充分利用資源。
• 離線任務(wù)這塊不用單獨(dú)申請(qǐng)計(jì)算資源，直接用我們?cè)诰€上的一些 CPU 內(nèi)存就好，存儲(chǔ)單獨(dú)去說(shuō)。

[[214428]]

吳磊，微信基礎(chǔ)平臺(tái)運(yùn)維負(fù)責(zé)人，2010 年加入 QQ 郵箱運(yùn)維團(tuán)隊(duì)，從微信第一個(gè)版本開始全程支撐從 0 到數(shù)億同時(shí)在線的野蠻生長(zhǎng)。目前負(fù)責(zé)消息收發(fā)、朋友圈等基礎(chǔ)業(yè)務(wù)運(yùn)維，專注自動(dòng)化運(yùn)維系統(tǒng)建設(shè)。