【51CTO.com原創(chuàng)稿件】互聯(lián)網(wǎng)技術(shù)一直在快速演進(jìn)當(dāng)中，同時移動互聯(lián)網(wǎng)與云時代的來臨，讓微服務(wù)架構(gòu)應(yīng)運(yùn)而生。

[[226446]]

2017 年 12 月 1 日-2 日，由 51CTO 主辦的 WOTD 全球軟件開發(fā)技術(shù)峰會在深圳中州萬豪酒店隆重舉行。

本次峰會以軟件開發(fā)為主題，熊普江先生在“微服務(wù)與容器技術(shù)”專場與來賓分享了"云端微服務(wù)架構(gòu)的運(yùn)維思考"的主題演講。

本文圍繞微服務(wù)架構(gòu)的特點(diǎn)與發(fā)展趨勢，結(jié)合微信業(yè)務(wù)在微服務(wù)架構(gòu)上的探索、應(yīng)用、改進(jìn)與提升，闡述運(yùn)維如何應(yīng)對業(yè)務(wù)在微服務(wù)架構(gòu)環(huán)境下的各種挑戰(zhàn)。

如今互聯(lián)網(wǎng)技術(shù)呈現(xiàn)出兩方面的發(fā)展趨勢：云化的趨勢和微服務(wù)。兩者相結(jié)合則更富挑戰(zhàn)性，本次我將以微信為例和大家一起探討。

本次分享分為三個方面：

• 微服務(wù)架構(gòu)的演進(jìn)
• 微服務(wù)架構(gòu)的特點(diǎn)與趨勢
• 微服務(wù)架構(gòu)運(yùn)維的解決之道

微服務(wù)架構(gòu)的演進(jìn)

智能手機(jī)在移動互聯(lián)網(wǎng)中的快速普及，中國互聯(lián)網(wǎng)中心的相關(guān)調(diào)查表明：通過手機(jī)上網(wǎng)的用戶比例已經(jīng)高達(dá) 93% 以上；而整個中國的互聯(lián)網(wǎng)滲透比例也已超過六成。

因此，我們所處的移動互聯(lián)網(wǎng)時代的開發(fā)呈現(xiàn)出如下的特征：

移動互聯(lián)時代全面來臨

雖然在工作時仍然離不開電腦，但是我們使用手機(jī)來連接互聯(lián)網(wǎng)的場景更為頻繁。

由于手機(jī)的運(yùn)算能力有限，手機(jī)更多地被用于展示或顯示內(nèi)容。大量功能化的計算處理顯然需要依賴于云端。所以我們實(shí)際上處于一個瘦客戶端的時代。

隨著我們停留在移動互聯(lián)網(wǎng)上的時間劇增，大量的數(shù)據(jù)也隨之產(chǎn)生，特別是相較于傳統(tǒng) PC 時代，增長了數(shù)十倍、乃至數(shù)百倍。

這些大量的數(shù)據(jù)同樣也需要在云端進(jìn)行處理，因此我們對于云服務(wù)的能力也會有一定的要求。

硬件技術(shù)發(fā)展迅速，服務(wù)器性能越來越大。如今硬件的處理能力（特別是 GPU）發(fā)展迅速，服務(wù)器的處理能力也得到了迅速提升。

這都導(dǎo)致了單個應(yīng)用或者單個功能模塊很難消耗掉整臺服務(wù)器的資源。為了提高多臺服務(wù)器的資源利用率，我們需要將多個服務(wù)部署到同一臺機(jī)器之上。

容器技術(shù)興起，輕量協(xié)議支持成熟應(yīng)用

在軟件方面，新興的技術(shù)包括：容器、Docker 和諸如 restful 之類的輕量協(xié)議，都加快了我們的開發(fā)與部署效率。

應(yīng)用的云化逐漸普及

為了將服務(wù)放到云端，我們不再需要去買各種機(jī)器，而直接在云上運(yùn)用各種資源來部署我們的服務(wù)。

該領(lǐng)域不僅是互聯(lián)網(wǎng)企業(yè)的熱點(diǎn)，其他傳統(tǒng)企業(yè)，包括一些金融和醫(yī)療企業(yè)也都在往云端尋求探索方向。

開發(fā)模式轉(zhuǎn)變

傳統(tǒng)的單體式集中開發(fā)模式為：前端 Web→管理系統(tǒng)→數(shù)據(jù)庫→操作系統(tǒng)→底層服務(wù)器。

這種從上到下的“縱切”方式勢必導(dǎo)致了對于技術(shù)人才、硬件、網(wǎng)絡(luò)、軟件、以及技術(shù)的大量需求。

這些對于初創(chuàng)型企業(yè)來說，會存在全能人才難招、開發(fā)復(fù)雜、遷移與擴(kuò)容難度大、無法快速的響應(yīng)等困難。

因此我們需要在開發(fā)和運(yùn)維方面轉(zhuǎn)變思路，通過“橫切”將底層資源和中間平臺轉(zhuǎn)包給 IaaS 和 PaaS 平臺，僅集中精力在前端的業(yè)務(wù)應(yīng)用上。

精細(xì)化運(yùn)營轉(zhuǎn)變

由于越來越多的服務(wù)都要經(jīng)由云端處理，以通過各種容器來實(shí)現(xiàn)快速部署與擴(kuò)展，因此我們必需使用精細(xì)運(yùn)維，來實(shí)現(xiàn)對于資源的充分利用。

基于上述移動互聯(lián)網(wǎng)時代的開發(fā)特征，一種適用于快速變化需求的微服務(wù)架構(gòu)應(yīng)運(yùn)而生，同時它也催生了 DevOps 的概念。

它是一種敏捷的開發(fā)模式架構(gòu)，能夠讓我們迅速地實(shí)現(xiàn)：編寫規(guī)劃→編寫代碼→構(gòu)建測試→發(fā)布上線→部署應(yīng)用。

近兩年，微服務(wù)這個術(shù)語漸成熱門詞匯，但它不是一個全新架構(gòu)，更不是一個包治百病的架構(gòu)。

那么，微服務(wù)架構(gòu)與單體式架構(gòu)相比優(yōu)勢體現(xiàn)在哪？這些優(yōu)勢又給開發(fā)模式、運(yùn)維帶來哪些挑戰(zhàn)？

微服務(wù)架構(gòu)的特點(diǎn)與趨勢

微服務(wù)架構(gòu)的特點(diǎn)與趨勢如下：

• 一種架構(gòu)風(fēng)格。微服務(wù)架構(gòu)實(shí)際上并非一種新的技術(shù)或能力，而只是一種架構(gòu)的風(fēng)格。它大約出現(xiàn)在 2014 年，但是微信早在 2011 年就開始使用該架構(gòu)風(fēng)格和思路進(jìn)行開發(fā)與運(yùn)維了。
• 強(qiáng)調(diào)服務(wù)的顆粒度、敏捷性和健壯性。微服務(wù)能夠?qū)崿F(xiàn)快速地開發(fā)、部署、和穩(wěn)健地運(yùn)行。
• 單一、獨(dú)立。微服務(wù)專注于解決單一問題，因此非常獨(dú)立。該獨(dú)立性體現(xiàn)在完成某個功能不依賴其他的服務(wù)，即如果該服務(wù)出錯，并不會影響到其他服務(wù)。
• 解耦，去中心化，組件化封裝。既然相對獨(dú)立，那么業(yè)務(wù)之間就是一種解耦的關(guān)系。縱觀整個應(yīng)用之中的各個服務(wù)，雖然重要程度有所區(qū)別，但是沒有一個服務(wù)必須以微服務(wù)為中心，因此它具有去中心化的特點(diǎn)。

為了能在與其他的微服務(wù)打交道時使用統(tǒng)一的接口，微服務(wù)也會進(jìn)行各種封裝。

• 多個微服務(wù)組合完成相對復(fù)雜的業(yè)務(wù)系統(tǒng)。我們能夠快速地將各個微服務(wù)組合到一起，構(gòu)建出一個能夠達(dá)到特定需求且相對復(fù)雜的業(yè)務(wù)系統(tǒng)。
• 高性能，高容錯。由于每個服務(wù)都相對獨(dú)立，就能夠在保持系統(tǒng)穩(wěn)定的前提下，***地追求每個微服務(wù)的性能。在分布式的結(jié)構(gòu)中，單個微服務(wù)的出錯（比如硬件出現(xiàn)問題）不會影響到其他的微服務(wù)。

另外在多個微服務(wù)并存時，同一個服務(wù)會有多個正在運(yùn)行當(dāng)副本，因此具有高容錯性。

微服務(wù)架構(gòu)解析

微服務(wù)架構(gòu)解析：

• 適用于構(gòu)建復(fù)雜的應(yīng)用，通過運(yùn)用微服務(wù)，可以將各種模塊如搭積木一般組合成相對復(fù)雜的應(yīng)用。
• 分布式，由于各個微服務(wù)之間都遵守相同的協(xié)議，可以實(shí)現(xiàn)多個微服務(wù)的分布式部署。
• 分別部署，由于每個微服務(wù)都具有單一且獨(dú)立的功能，因此服務(wù)模塊的數(shù)量顯然是龐大的，光靠人工完全無法實(shí)現(xiàn)分開部署。隨著微服務(wù)的數(shù)量呈幾何基數(shù)增長，我們需要用一套自動化的工具來進(jìn)行快速地部署。
• 服務(wù)組件，微服務(wù)一般分為兩種不同的類別：一是基礎(chǔ)模塊或稱公共模塊。如：用戶登錄、推送（Push）服務(wù)模塊；另一是功能性模塊，如：實(shí)現(xiàn)發(fā)消息或發(fā)朋友圈的模塊。
• 微服務(wù)的邊界，雖然用的是同一種語言，但是可以進(jìn)行獨(dú)立地開發(fā)與測試，因此每個微服務(wù)在被發(fā)布的時候不會跟其他的微服務(wù)共享數(shù)據(jù)存儲或內(nèi)存空間。每個微服務(wù)都有自己的獨(dú)立空間。
• API 層，如上圖所示，微服務(wù)與外界有一個接口層，它們遵守共同的協(xié)議進(jìn)行通信，如 RPC 或 Restful 等，大家可以自由選擇各種技術(shù)。
• 微服務(wù)架構(gòu)的擴(kuò)展，為了應(yīng)對未來可能對現(xiàn)有微服務(wù)的功能性增加，或是要增加其他業(yè)務(wù)場景，我們一般不在原有微服務(wù)上著手增加，而是新建另一個微服務(wù)，并獨(dú)立部署。

微服務(wù)架構(gòu)的優(yōu)勢

微服務(wù)架構(gòu)有如下幾個明顯的優(yōu)勢：

• 單個微服務(wù)更易理解，方便開發(fā)與維護(hù)。相比以往，只要定義好了一個微服務(wù)，我們在開發(fā)、維護(hù)和部署時就能方便地理解其功能意圖。
• 應(yīng)用解耦、對應(yīng)用整體應(yīng)用交付而言，開發(fā)迭代更敏捷。我們可以單獨(dú)對一個微服務(wù)進(jìn)行升級，而不會影響其他微服務(wù)的功能。
• 技術(shù)選擇更加自由，微服務(wù)不再需要限定某個統(tǒng)一的技術(shù)實(shí)現(xiàn)。每個程序員都有自己的技術(shù)偏好，有人喜歡 Java，也有人喜歡 PHP 或是 C。
• 以往大家不得不根據(jù)統(tǒng)一技術(shù)框架，遵循一致的開發(fā)語言。如今每個微服務(wù)都可以用不同的語言來實(shí)現(xiàn)。
• 微服務(wù)獨(dú)立部署，應(yīng)用更穩(wěn)定。由于每個微服務(wù)都不影響其他的微服務(wù)，因此單獨(dú)部署會給整體應(yīng)用帶來更好的穩(wěn)定性。
• 架構(gòu)擴(kuò)展更容易、更快速。如右圖所示，我們從三個維度進(jìn)行架構(gòu)設(shè)計。其中 X 軸表示可以放置多個副本；Y 軸是通過分層來擴(kuò)容服務(wù)；而 Z 軸是對服務(wù)進(jìn)行數(shù)據(jù)分區(qū)。
• 這說明我們的微服務(wù)能從 X、Y、Z 三個方向去擴(kuò)展整體架構(gòu)。

微服務(wù)架構(gòu)帶來的挑戰(zhàn)

下面是談?wù)勔胛⒎?wù)架構(gòu)時會碰到的各種挑戰(zhàn)：

• 開發(fā)模式需要相應(yīng)調(diào)整，首先要從“縱切”的開發(fā)思維轉(zhuǎn)變成“橫切”的思維。
• 跟以往相比，微服務(wù)的數(shù)量會大幅增加。
• 數(shù)據(jù)增多導(dǎo)致了容器的編排、配置與資源的管理更為復(fù)雜。相對于過去只需管幾臺機(jī)器而言，如今如何搭配和配置各種微服務(wù)會變得更復(fù)雜。
• 業(yè)務(wù)的容量管理變得更加困難，資源利用效率難以提升。以前我們只需要監(jiān)控某幾臺機(jī)器的使用率。
• 如今，由于容器存在多臺服務(wù)器上，就需要對容器里各種服務(wù)的資源利用率和容量進(jìn)行綜合管理，同時對它們的提升難度也更大了。
• 監(jiān)控的顆粒度增多，依賴及關(guān)聯(lián)關(guān)系更加復(fù)雜。由于微服務(wù)的增多，監(jiān)控的顆粒也相應(yīng)有所增加。如上圖右側(cè)所示，顆粒之間的關(guān)聯(lián)關(guān)系也會變得更加復(fù)雜。
• 在微服務(wù)出現(xiàn)故障時，我們要有快速調(diào)度的能力，因此調(diào)度需要更精細(xì)化。

微服務(wù)架構(gòu)下的運(yùn)維思考

下面是我在微服務(wù)架構(gòu)下的一些運(yùn)維思考：

• 容量管理，即：如何在細(xì)粒度的狀態(tài)下，更有效地管理數(shù)量龐大的微服務(wù)。
• 容器編排與配置管理，如何合理地實(shí)現(xiàn)容器編排和配置管理？
• 服務(wù)監(jiān)控，如何有效地監(jiān)控數(shù)量龐大的微服務(wù)？
• 故障恢復(fù)與業(yè)務(wù)調(diào)度，出現(xiàn)故障時如何進(jìn)行業(yè)務(wù)調(diào)度？
• 快速擴(kuò)展，由于春節(jié)紅包或直播所導(dǎo)致的業(yè)務(wù)爆炸式增長或觸發(fā)時，如何快速擴(kuò)容？
• 資源的利用效率，運(yùn)維人員需要思考如何在保障業(yè)務(wù)穩(wěn)定發(fā)展的同時，控制好成本不會大幅增長，資源不會出現(xiàn)簡單堆砌。

微服務(wù)架構(gòu)運(yùn)維的解決之道

下面先以微信為例，講解它使用到微服務(wù)架構(gòu)的地方，接著介紹我們在微服務(wù)容量管理方面的具體工作，然后給大家分享在監(jiān)控部署調(diào)度上值得參考的地方，***探討我們在資源利用率上的精細(xì)化運(yùn)營。

微信為什么要微服務(wù)云化

自 2011 年誕生以來，微信一直強(qiáng)調(diào)使用快速迭代、試錯、糾正的敏捷開發(fā)模式，也就是我們常說的“小步快跑”方式。

在微信內(nèi)部有四個“法器”，分別是：

• 大系統(tǒng)小做
• 讓一切可擴(kuò)展
• 有基礎(chǔ)的組件
• 能夠輕松地上線

大系統(tǒng)小做，不僅涉及到將海量系統(tǒng)中的模塊變得更清晰，而且在物理環(huán)境中實(shí)現(xiàn)分開獨(dú)立的部署，以便快速發(fā)現(xiàn)問題。

例如：一些公共服務(wù)的注冊登錄、LBS 的邏輯、和類似微信的搖一搖等方面，我們都將這些邏輯獨(dú)立了出來。

讓一切可擴(kuò)展，此處強(qiáng)調(diào)兩個方面：

• 網(wǎng)絡(luò)協(xié)議的擴(kuò)展。通過向前兼容，以應(yīng)對將來可能出現(xiàn)的升級。
• 數(shù)據(jù)存儲的擴(kuò)展。傳統(tǒng)的 MySQL 之類的結(jié)構(gòu)化數(shù)據(jù)存儲，對于后期頻繁增加字段的擴(kuò)展性并不方便。因此微信采用的是 Key-Value 的非結(jié)構(gòu)化數(shù)據(jù)結(jié)構(gòu)，以方便存儲上的擴(kuò)展。

在 2013 年到 2014 年間，微信的微服務(wù)模塊數(shù)已超過了 5000 個，我們碰到過兩個問題：

• 如果在一臺硬件能力超強(qiáng)的服務(wù)器上只部署一個模塊，則勢必造成資源浪費(fèi)。因此我們采用了混合部署，在一個服務(wù)器上部署多個服務(wù)。
• 多個服務(wù)在一臺服務(wù)器上搶資源，從而影響了服務(wù)的穩(wěn)定性。因此我們采用了容器隔離。

有基礎(chǔ)的組件，把復(fù)雜的邏輯固化下來，成為基礎(chǔ)性軟件。在微信的后臺會有幾種不同的基礎(chǔ)組件，大致包括：

• Svrkit，Client/Server自動代碼生成框架，實(shí)現(xiàn) 10 分鐘搭建內(nèi)部服務(wù)器。
• LogicServer，邏輯容器：隨時添加新邏輯。
• OssAgent，監(jiān)控/統(tǒng)計框架：所見即所得的監(jiān)控報表。
• 存儲組件，屏蔽容災(zāi)/擴(kuò)容等復(fù)雜問題。

微信微服務(wù)架構(gòu)的應(yīng)用與管理

我們對微信里的各個微服務(wù)應(yīng)用場景進(jìn)行了定義：

• 服務(wù)布局，就是將用戶運(yùn)用不同的方法與服務(wù)維度進(jìn)行“切割”和布局。
• 引入各種容錯機(jī)制，如：當(dāng)服務(wù)訪問中斷時，可自動重試；當(dāng)服務(wù)運(yùn)能不夠時，有過載保護(hù)和負(fù)載均衡；在必要時，可隨時關(guān)閉服務(wù)，實(shí)現(xiàn)柔性可用。
• 容量管理與監(jiān)控。
• 部署管理與調(diào)度。
• 精細(xì)化運(yùn)營。

我們對微服務(wù)也進(jìn)行了技術(shù)分層：

• 接入層，主要實(shí)現(xiàn)對用戶的切分，以識別不同的運(yùn)營商和不同的地域。
• 邏輯層，在微信中，微服務(wù)被更多地應(yīng)用在邏輯層。
• 存儲層，主要應(yīng)對海量數(shù)據(jù)，以及獨(dú)占資源的情況。

服務(wù)布局

微信采用多地自治、園區(qū)互備的架構(gòu)，城市之間的數(shù)據(jù)是相對獨(dú)立的。除了少數(shù)賬號全球同步以外，大部分業(yè)務(wù)都以電子郵件式的服務(wù)，各自有自身的環(huán)境在流轉(zhuǎn)和通信。城市間的后備則使用公網(wǎng)的 UDP 通道。

在城市內(nèi)，使用三園區(qū)的架構(gòu)，每個園區(qū)都是一套獨(dú)立的系統(tǒng)，從接入、邏輯、存儲每一層都是完全獨(dú)立的，并且可以互相為對方提供備份，多園區(qū)形成整體服務(wù)規(guī)模。

在園區(qū)內(nèi)，由多機(jī)組成的 set，互為容錯，包含它們的網(wǎng)絡(luò)與電力也是獨(dú)立的。這樣的服務(wù)布局，不僅滿足微服務(wù)架構(gòu)，也考慮了容災(zāi)能力。

過載保護(hù)

過載保護(hù)是一個非常核心的微服務(wù)架構(gòu)特性，目的是確保核心服務(wù)可用。

它包括三個層次：

• 服務(wù)要有輕重分離。即一個服務(wù)里不能既有重的操作，又有輕的操作。
• 隊列控制。我們通過監(jiān)控，來了解一個請求在隊列中等待的平均時間，從而決定是否要啟動拒絕或是限流。例如：對超過設(shè)定閥值的流量進(jìn)行限制，確保服務(wù)可用。
• 組合命令式。由于微服務(wù)的調(diào)用鏈以及層次的增多，后端服務(wù)也會有多種。假定后端有兩個服務(wù)（A 服務(wù)與 B 服務(wù)），而前端調(diào)用需要依賴于 A、B 服務(wù)的組合結(jié)果，那么單個 A 或者單個 B 的輕微過載，就可能導(dǎo)致前端服務(wù)不可用。

在這種情況下，需要有一個反饋機(jī)制。如上圖所示，整個系統(tǒng)基于反饋，把整個拒絕的信息全程傳遞。上圖右側(cè)是幾個典型的服務(wù)，從一個 CGI 調(diào)用一個后臺服務(wù)，再調(diào)用另一個后臺服務(wù)，系統(tǒng)會在 CGI 層面把它的重要程度往下傳。

回到剛才前端調(diào)用 A、B 服務(wù)的例子，使用這樣一種重要程度的傳遞，就可以直接拒絕那些相同用戶的 20% 的請求，有效地解決單個服務(wù)輕微過載的問題。

容量管理

為了在微服務(wù)架構(gòu)下實(shí)行較好的容量關(guān)系，微信做到了三個前提：

• 微服務(wù)間資源進(jìn)行隔離管理
• 微服務(wù)的過載有自我保護(hù)能力
• 服務(wù)的快速伸縮操作

容量管理是為了更好地進(jìn)行業(yè)務(wù)支撐，因此我們構(gòu)建了需要支撐的業(yè)務(wù)與其容量之間的模型關(guān)系，從而有效地評估出那些有效的微服務(wù)所對應(yīng)的容量。

如上圖所示，下方的灰色線表示實(shí)際業(yè)務(wù)的容量，即業(yè)務(wù)量，如：請求量、調(diào)用量、以及用戶數(shù)。

紅色線表示在機(jī)器擴(kuò)容或升級之后的現(xiàn)網(wǎng)容量。綠色線則表示***容量，它比現(xiàn)網(wǎng)容量要高出 20%，以保證只是偶爾被觸發(fā)。

當(dāng)業(yè)務(wù)需求超過現(xiàn)有容量時，業(yè)務(wù)就可能出現(xiàn)不穩(wěn)定或者無法提供服務(wù)的情況。而擴(kuò)容則往往涉及到復(fù)雜的數(shù)學(xué)運(yùn)算。

因此由于現(xiàn)實(shí)中資源的采購、部署與上架存在周期，不大可能完全達(dá)到該綠色曲線。

隨著公有云被廣泛地運(yùn)用，我們基本上能夠?qū)崿F(xiàn)及時獲取容量資源。當(dāng)然要保證具有較好的業(yè)務(wù)支撐的話，應(yīng)當(dāng)具有容量的發(fā)現(xiàn)能力和適當(dāng)?shù)奶幚硇省?/p>

在實(shí)際進(jìn)行容量評估的時候，可能會碰到如上圖所示的“坑點(diǎn)”：我們可能會將容量誤解為左邊的線性關(guān)系。

在某些時候，使用量上升到 60% 之前還是處于線性，可一旦升至 65% 或 80% 時，就會維持那么多且再也上不去了，如右邊的容量模型所示。

所以說容量評估的困難之處就在于：一個應(yīng)用或一個微服務(wù)在使用資源時會受到諸如：CPU、內(nèi)存、網(wǎng)絡(luò)、以及磁盤 I/O 等多種因素的制約。

因此，我們應(yīng)當(dāng)去熟悉某個微服務(wù)主要消耗資源的關(guān)鍵點(diǎn)，以及它與其他資源之間的關(guān)系。

針對容量的評估，同樣在微信中引入了壓測。如圖所示，我們有四種模擬測試的方案：

• 模擬流量到測試環(huán)境，它對現(xiàn)網(wǎng)不產(chǎn)生影響。這往往由測試團(tuán)隊來操作。
• 真實(shí)流量到測試環(huán)境，即運(yùn)用 TCP 協(xié)議復(fù)制一份流量到測試環(huán)境。許多電商經(jīng)常在一些大促之前，會把一些真實(shí)的流量引到測試環(huán)境之中，以檢驗(yàn)系統(tǒng)到底能支撐多久。這往往由運(yùn)維和開發(fā)協(xié)同執(zhí)行。
• 模擬流量到現(xiàn)網(wǎng)環(huán)境，這種并不常見。
• 真實(shí)流量到真實(shí)環(huán)境，這是在微信中使用最多主要的現(xiàn)網(wǎng)壓測方式。該方法雖然最真實(shí)、且對容量的評估也最準(zhǔn)確，但也會有***的風(fēng)險。它可能會引發(fā)故障，并考驗(yàn)我們及時發(fā)現(xiàn)故障點(diǎn)的能力。

壓測具有雙面性，好的一面在于：有助于我們發(fā)現(xiàn)過去未曾注意的底層問題；不好的一面，則是在出現(xiàn)問題之后，我們可能無法快速地恢復(fù)，有時甚至并非將流量撤掉那么簡單。

因?yàn)橐坏┠硞€服務(wù)崩潰了，則需要花時間和精力重新啟動它。因此我們在做真實(shí)壓測時，會特別注意上圖所列的三點(diǎn)。

上圖展示了過載保護(hù)的機(jī)制。當(dāng)有更多的流量抵達(dá)時，過剩的流量會被直接拒絕掉，顯然我們也可籍此測算出其真實(shí)的流量大小。

可見過載保護(hù)，或稱快速拒絕是在微服務(wù)架構(gòu)下做好容量管理的重要前提。如果沒有該保護(hù)，將很難評估現(xiàn)網(wǎng)容量的門限。

微服務(wù)監(jiān)控

微信實(shí)現(xiàn)了對于微服務(wù)的立體化監(jiān)控，監(jiān)控的內(nèi)容包括：

• 常規(guī)指標(biāo)，如 CPU、內(nèi)存、網(wǎng)卡等。
• 快速拒絕的數(shù)量級，通過該數(shù)量級，可以進(jìn)一步評估受影響的用戶量。
• 耗時方面的精確數(shù)據(jù)。
• 調(diào)用失敗的次數(shù)、重試的次數(shù)。

這些在監(jiān)控上都有一些數(shù)據(jù)來上報及展現(xiàn)。由于我們監(jiān)控指標(biāo)非常多，同時伴隨著微服務(wù)的增多，其產(chǎn)生的報警數(shù)量也會呈爆炸式增長。因此需要有智慧化的運(yùn)維，通過 AI 應(yīng)用去收斂各種報警。

就監(jiān)控能力而言，我們?yōu)槊颗_機(jī)器都部署了 Agent。這些 Agent 的監(jiān)控粒度比較密集，能夠達(dá)到秒級監(jiān)控。與此同時，它們的數(shù)據(jù)上報能力也較為迅速。

業(yè)務(wù)部署與調(diào)度

容器的編排是微服務(wù)的一個重要方面，不同于 Docker，微信采用的是自研的 svrkit 架構(gòu)，它參考了 borg/yarn/k8s/mesos 等主流調(diào)度系統(tǒng)的特點(diǎn)，該容器調(diào)度的微服務(wù)覆蓋率超過 80%。

微信的容器調(diào)度系統(tǒng)叫做 yard。如上圖下方所示，它分為兩層架構(gòu)：

• Resource Manager 和 Node Manager，負(fù)責(zé)資源管理。
• Application Master 和 API/Query Server，負(fù)責(zé)作業(yè)管理。

資源管理的監(jiān)控能夠決定出：在哪個容器中將哪個應(yīng)用“拉起來”，而在哪個容器里將其“下線”。

雖然該容器編排架構(gòu)屬于微信自研、且尚未對外開放，但是其調(diào)度能力已逐步開放到了騰訊云之上。

騰訊云提供了包括集群管理、資源調(diào)度、以及鏡像倉庫等方面的結(jié)合。其對應(yīng)的產(chǎn)品包括 CCS（容器管理）、API 網(wǎng)關(guān)、以及分布式微服務(wù)的架構(gòu)管理等。

微服務(wù)精細(xì)化運(yùn)營

精細(xì)化運(yùn)營要做到對資源進(jìn)行“削峰填谷”。通過了解業(yè)務(wù)的特性，掌握每個業(yè)務(wù)峰值的不同時間，從而將資源盡可能控制在上圖的藍(lán)色線條附近。

例如：微信的游戲里有一個功能模塊，在凌晨零點(diǎn)的時候開始新發(fā)禮品。此時該模塊對于資源的需求會劇增，而同一時刻其他模塊的資源消耗并不多。

因此我們就可以把該游戲發(fā)禮品的微服務(wù)部署到其他模塊服務(wù)器資源之上，從而削除它的峰值，達(dá)到了錯峰服務(wù)的效果。

我們在許多場景中會用到離線計算，如：各種日志分析、應(yīng)用數(shù)據(jù)分析、以及人工智能方面的訓(xùn)練。

這些都是可以使用到離線計算的業(yè)務(wù)，多數(shù)不需要實(shí)時，它們都可以被部署在資源谷底的時候。

微服務(wù)的未來演進(jìn)

我們采用微服務(wù)架構(gòu)之后，有些問題也值得我們?nèi)フJ(rèn)真思考：

• 微服務(wù)這么多，我們能否延用以往的 CMDB 方式進(jìn)行有效地管理呢？特別是那些放在公有云端的微服務(wù)，如何將它們納入現(xiàn)有的 CMDB 呢？
• 是否有更好的微服務(wù)管理工具，來實(shí)現(xiàn)服務(wù)可視化、消息跟蹤和智能故障檢測？
• 是否有微服務(wù)的應(yīng)用商店，來幫助我們快速地開發(fā)各種應(yīng)用？

[[226451]]

熊普江，騰訊公司資深架構(gòu)師 ，負(fù)責(zé)公司騰訊云技術(shù)、解決方案布道與技術(shù)架構(gòu)評審等工作。騰訊公司級課程講師，GITC 專家顧問，WOT 特約講師，GOPS 金牌講師。自 1997 年涉足互聯(lián)網(wǎng)，曾服務(wù)美國 Supreme、太平洋網(wǎng)絡(luò)、PPTV 等互聯(lián)網(wǎng)公司，任網(wǎng)絡(luò)運(yùn)營總監(jiān)、運(yùn)維總監(jiān)等職務(wù)。近 20 年互聯(lián)網(wǎng)從業(yè)背景，對大型網(wǎng)絡(luò)架構(gòu)規(guī)劃與建設(shè)，海量用戶平臺規(guī)劃與運(yùn)營技術(shù)支持，超大規(guī)模業(yè)務(wù)資源規(guī)劃與技術(shù)架構(gòu)管理優(yōu)化有豐富的經(jīng)驗(yàn)。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】