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

[[214411]]

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

我們在 2014 年以后增長有點放緩，所以主要的精力會在成本這個方面。

如上圖，下面我主要分為四個方面來做分享：

• 運營規(guī)范。
• 云化管理。
• 容量管理。
• 自動調(diào)度。

運營規(guī)范

配置文件規(guī)范

先來看配置文件規(guī)范，我們前期花了比較多的精力。可能整個系統(tǒng)設(shè)計比較復(fù)雜，最開始都會有一些配置管理工程師專門來處理，后期我們把這塊搞得比較規(guī)范了。

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

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

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

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

為什么提這一點？可能有些配置項你會在這個服務(wù)里需要這幾個配置項，在另一個服務(wù)里也需要這幾個配置項。

如果更改這個配置項的時候，你是不是把服務(wù) A 發(fā)一遍，服務(wù) B 也發(fā)一遍？我們有一套機制，每臺機每個目錄下都會有一個全局共用的配置項，我們會通過一些自動化的灰度的方式來控制這里的發(fā)布，這一塊是單獨拎出來的。

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

不確定大家運營時會不會碰到類似的問題，就算你用 Docker 了你鏡像管理挺好的。

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

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

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

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

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

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

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

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

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

• 接入層，類 LVS 實現(xiàn)。
• 邏輯層，類 etcd 實現(xiàn)。
• 存儲層，路由配置自動化。

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

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

存儲層跟 QQ 有點不一樣，QQ 好像是邏輯層和存儲層都是用同一個名字服務(wù)實現(xiàn)，我們在存儲層這里還沒有做這方面的配置。

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

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

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

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

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

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

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

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

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

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

接入層不帶數(shù)據(jù)，其實歷史上我們也有一次是帶了數(shù)據(jù)的，在每次過年搶紅包的時候，所有人都在搖的那一把，那個量是非常恐怖的。

搖紅包那個點我們做設(shè)計是每個搖紅包的請求真的打到我們接入層，不會有客戶端搖五次才有一次請求上來。

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

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

運營規(guī)范小結(jié)

運營規(guī)范小結(jié)：

• 階段目標(biāo)

服務(wù)可運維

• 落實措施

變更系統(tǒng)攔截

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

這里說了幾點，我們的目標(biāo)簡單來說就是服務(wù)可運維，可運維的意思就是你做擴容縮容的時候不需要做人工的操作，如果做人工的操作就是不可運維。

為了實現(xiàn)服務(wù)可運維，我們在變更系統(tǒng)里做了一些攔截，它接下來變更可能不符合我們運營規(guī)范或者之前有不符合我們運營規(guī)范的地方，我們都會攔下來，要求變更，實現(xiàn)我們的運維規(guī)范。

云化管理

接下來說一下云，大家用云也挺多的，近幾年也比較火，可能大家用得比較多的是 Docker，微信這邊我們沒有用 Docker，后面也會說到為什么沒有用的原因。

為什么上云

上云的兩點原因：

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

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

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

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

最開始說微服務(wù)這個事情的時候，我記得是 QQ 那邊海量運營的一些課程都會提到，我覺得這個思路跟微服務(wù)是完全一致的。

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

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

哪部分上云

哪部分上云：

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

哪一塊上云，剛才也說到，接入層因為要扛住比較猛的量，微信的用戶也比較多，如果它有什么問題，可能接入層會雪崩。

所以我們主要是獨占物理機，容量足，變更也少，暫時沒有上云的需求。

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

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

基于 Cgroup 的云化

基于 Cgroup 的云化：

• 虛擬機型定制

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

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

• 物理機分片

我們云的方式是直接 Cgroup，Cgroup 這個名字可能有些人不知道，我們用的是內(nèi)核 Cgroup 這種機制。

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

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

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

這個我們也有一些比較特殊的方法來處理。

線上未啟用 Docker

我們沒有用 Docker 的幾點原因：

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

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

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

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

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

可以說Docker解決的一些問題在我們這里不是問題：

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

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

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

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

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

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

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

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

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

云化管理小結(jié)

云化管理小結(jié)：

• 階段目標(biāo)

服務(wù)間資源隔離

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

• 落實措施

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

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

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

第二是服務(wù)伸縮頁面化操作，有些服務(wù)還是很龐大的，一個服務(wù)下幾千上萬臺都可能，這種時候不希望你上機器的，在頁面上點就可以了。

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

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

容量管理

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

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

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

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

第二個點是處理效率，容量不足的時候把曲線打上去，擴容需要多長時間，如果是幾天或者幾分鐘，這個效率是不一樣的。

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

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

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

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

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

使用 CPU 評估容量

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

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

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

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

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

真實案例

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

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

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

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

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

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

壓測方式

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

• 一種是模擬流量
• 一種真實流量

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

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

四種壓測方式：

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

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

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

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

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

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

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

服務(wù)的自我保護

你的各個服務(wù)有沒有做好自我保護。我們引入了一個快速拒絕的概念，這個服務(wù)正常的時候，可能你的上線每分鐘 100 萬個請求也是能正常服務(wù)的。

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

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

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

立體化監(jiān)控

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

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

秒級監(jiān)控

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

整個實現(xiàn)的方式大家應(yīng)該都差不多，每臺機都有個采集的，之前是每分鐘上報一次到隊列，然后再匯總，然后再入庫。

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

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

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

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

這個點大家很明顯看到一個問題，運維在壓測的時候其實是給自己找事，每次壓測都打上來，又掉下去，打上來。

失敗曲線就像狗啃的一樣，一直有抖來抖去的曲線。這種壓測方式，運維自己都受不了。

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

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

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

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

這是我們真實的線上壓縮的結(jié)果。這張圖打出來的斜率是先漲得比較快，后期再慢慢增長，然后把這個壓測點停掉了。

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

容量管理小結(jié)

這個事情我們做完了，覺得有幾方面的收益：

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

自動調(diào)度

業(yè)務(wù)增長的自動擴容

解決業(yè)務(wù)增長的自動擴容，因為你的業(yè)務(wù)量在漲，你的用戶的請求包括各種請求量都是跟著指標(biāo)在漲的。

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

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

我們會留出一些時間給采購機器給我們，會把一些服務(wù)的流量控制在50%這個點。

異常情況的自動擴容

還有一些異常的情況：

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

程序性能下降的合理性評估

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

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

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

性能管理閉環(huán)

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

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

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

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

還有一種是最底下這種，比較典型的例子是微信活動，微信活動好像是晚上 22 點的時候會來一步。

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

削峰填谷

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

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

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

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

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

離線計算填谷

離線計算填谷：

• 離線任務(wù)的運行時段

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

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

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

cpu.shares + memory.limit_in_bytes + blkio

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

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

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

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

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

這在自動調(diào)度這塊是我們實現(xiàn)的一個目標(biāo)：

• 全盤控制所有的在線服務(wù)，充分利用資源。
• 離線任務(wù)這塊不用單獨申請計算資源，直接用我們在線上的一些 CPU 內(nèi)存就好，存儲單獨去說。

[[214428]]

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