【51CTO.com原創稿件】互聯網技術一直在快速演進當中， 同時移動互聯網與雲時代的來臨， 讓微服務架構應運而生。
2017 年 12 月 1 日-2 日， 由 51CTO 主辦的 WOTD 全球軟體發展技術峰會在深圳中州萬豪酒店隆重舉行。
本次峰會以軟體發展為主題， 熊普江先生在“微服務與容器技術”專場與來賓分享了"雲端微服務架構的運維思考"的主題演講。
本文圍繞微服務架構的特點與發展趨勢， 結合微信業務在微服務架構上的探索、應用、改進與提升， 闡述運維如何應對業務在微服務架構環境下的各種挑戰。
如今互聯網技術呈現出兩方面的發展趨勢：雲化的趨勢和微服務。 兩者相結合則更富挑戰性， 本次我將以微信為例和大家一起探討。
本次分享分為三個方面：
微服務架構的演進
微服務架構的特點與趨勢
微服務架構運維的解決之道
微服務架構的演進
智慧手機在移動互聯網中的快速普及，
因此， 我們所處的移動互聯網時代的開發呈現出如下的特徵：
移動互聯時代全面來臨
雖然在工作時仍然離不開電腦， 但是我們使用手機來連接互聯網的場景更為頻繁。
由於手機的運算能力有限， 手機更多地被用於展示或顯示內容。 大量功能化的計算處理顯然需要依賴於雲端。 所以我們實際上處於一個精簡型用戶端的時代。
隨著我們停留在移動互聯網上的時間劇增， 大量的資料也隨之產生， 特別是相較于傳統 PC 時代， 增長了數十倍、乃至數百倍。
這些大量的資料同樣也需要在雲端進行處理，
硬體技術發展迅速， 伺服器性能越來越大。 如今硬體的處理能力（特別是 GPU）發展迅速， 伺服器的處理能力也得到了迅速提升。
這都導致了單個應用或者單個功能模組很難消耗掉整台伺服器的資源。 為了提高多台伺服器的資源利用率， 我們需要將多個服務部署到同一台機器之上。
容器技術興起， 輕量協議支援成熟應用
在軟體方面， 新興的技術包括：容器、Docker 和諸如 restful 之類的輕量協議， 都加快了我們的開發與部署效率。
應用的雲化逐漸普及
為了將服務放到雲端， 我們不再需要去買各種機器， 而直接在雲上運用各種資源來部署我們的服務。
該領域不僅是互聯網企業的熱點，
開發模式轉變
傳統的單體式集中開發模式為：前端 Web→管理系統→資料庫→作業系統→底層伺服器。
這種從上到下的“縱切”方式勢必導致了對於技術人才、硬體、網路、軟體、以及技術的大量需求。
這些對於初創型企業來說， 會存在全能人才難招、開發複雜、遷移與擴容難度大、無法快速的回應等困難。
因此我們需要在開發和運維方面轉變思路， 通過“橫切”將底層資源和中間平臺轉包給 IaaS 和 PaaS 平臺， 僅集中精力在前端的業務應用上。
精細化運營轉變
由於越來越多的服務都要經由雲端處理， 以通過各種容器來實現快速部署與擴展， 因此我們必需使用精細運維， 來實現對於資源的充分利用。
基於上述移動互聯網時代的開發特徵，一種適用於快速變化需求的微服務架構應運而生，同時它也催生了 DevOps 的概念。
它是一種敏捷的開發模式架構，能夠讓我們迅速地實現：編寫規劃→編寫代碼→構建測試→發佈上線→部署應用。
近兩年，微服務這個術語漸成熱門詞彙，但它不是一個全新架構，更不是一個包治百病的架構。
那麼，微服務架構與單體式架構相比優勢體現在哪？這些優勢又給開發模式、運維帶來哪些挑戰？
微服務架構的特點與趨勢
微服務架構的特點與趨勢如下：
一種架構風格。微服務架構實際上並非一種新的技術或能力，而只是一種架構的風格。它大約出現在 2014 年，但是微信早在 2011 年就開始使用該架構風格和思路進行開發與運維了。
強調服務的顆粒度、敏捷性和健壯性。微服務能夠實現快速地開發、部署、和穩健地運行。
單一、獨立。微服務專注于解決單一問題，因此非常獨立。該獨立性體現在完成某個功能不依賴其他的服務，即如果該服務出錯，並不會影響到其他服務。
解耦，去中心化，元件化封裝。既然相對獨立，那麼業務之間就是一種解耦的關係。縱觀整個應用之中的各個服務，雖然重要程度有所區別，但是沒有一個服務必須以微服務為中心，因此它具有去中心化的特點。
為了能在與其他的微服務打交道時使用統一的介面，微服務也會進行各種封裝。
多個微服務組合完成相對複雜的業務系統。我們能夠快速地將各個微服務組合到一起，構建出一個能夠達到特定需求且相對複雜的業務系統。
高性能，高容錯。由於每個服務都相對獨立，就能夠在保持系統穩定的前提下，極致地追求每個微服務的性能。在分散式的結構中，單個微服務的出錯（比如硬體出現問題）不會影響到其他的微服務。
另外在多個微服務並存時，同一個服務會有多個正在運行當副本，因此具有高容錯性。
微服務架構解析
微服務架構解析：
適用於構建複雜的應用，通過運用微服務，可以將各種模組如搭積木一般組合成相對複雜的應用。
分散式，由於各個微服務之間都遵守相同的協議，可以實現多個微服務的分散式部署。
分別部署，由於每個微服務都具有單一且獨立的功能，因此服務模組的數量顯然是龐大的，光靠人工完全無法實現分開部署。隨著微服務的數量呈幾何基數增長，我們需要用一套自動化的工具來進行快速地部署。
服務元件，微服務一般分為兩種不同的類別：一是基礎模組或稱公共模組。如：使用者登錄、推送（Push）服務模組；另一是功能性模組，如：實現發消息或發朋友圈的模組。
微服務的邊界，雖然用的是同一種語言，但是可以進行獨立地開發與測試，因此每個微服務在被發佈的時候不會跟其他的微服務共用資料存儲或記憶體空間。每個微服務都有自己的獨立空間。
API 層，如上圖所示，微服務與外界有一個介面層，它們遵守共同的協議進行通信，如 RPC 或 Restful 等，大家可以自由選擇各種技術。
微服務架構的擴展，為了應對未來可能對現有微服務的功能性增加，或是要增加其他業務場景，我們一般不在原有微服務上著手增加，而是新建另一個微服務，並獨立部署。
微服務架構的優勢
微服務架構有如下幾個明顯的優勢：
單個微服務更易理解，方便開發與維護。相比以往，只要定義好了一個微服務，我們在開發、維護和部署時就能方便地理解其功能意圖。
應用解耦、對應用整體應用交付而言，開發反覆運算更敏捷。我們可以單獨對一個微服務進行升級，而不會影響其他微服務的功能。
技術選擇更加自由，微服務不再需要限定某個統一的技術實現。每個程式師都有自己的技術偏好，有人喜歡 Java，也有人喜歡 PHP 或是 C。
以往大家不得不根據統一技術框架，遵循一致的開發語言。如今每個微服務都可以用不同的語言來實現。
微服務獨立部署，應用更穩定。由於每個微服務都不影響其他的微服務，因此單獨部署會給整體應用帶來更好的穩定性。
架構擴展更容易、更快速。如右圖所示，我們從三個維度進行架構設計。其中 X 軸表示可以放置多個副本；Y 軸是通過分層來擴容服務；而 Z 軸是對服務進行資料分區。
這說明我們的微服務能從 X、Y、Z 三個方向去擴展整體架構。
微服務架構帶來的挑戰
下面是談談引入微服務架構時會碰到的各種挑戰：
開發模式需要相應調整，首先要從“縱切”的開發思維轉變成“橫切”的思維。
跟以往相比，微服務的數量會大幅增加。
資料增多導致了容器的編排、配置與資源的管理更為複雜。相對于過去只需管幾台機器而言，如今如何搭配和配置各種微服務會變得更複雜。
業務的容量管理變得更加困難，資源利用效率難以提升。以前我們只需要監控某幾台機器的使用率。
如今，由於容器存在多台伺服器上，就需要對容器裡各種服務的資源利用率和容量進行綜合管理，同時對它們的提升難度也更大了。
監控的顆粒度增多，依賴及關聯關係更加複雜。由於微服務的增多，監控的顆粒也相應有所增加。如上圖右側所示，顆粒之間的關聯關係也會變得更加複雜。
在微服務出現故障時，我們要有快速調度的能力，因此調度需要更精細化。
微服務架構下的運維思考
下面是我在微服務架構下的一些運維思考：
容量管理，即：如何在細細微性的狀態下，更有效地管理數量龐大的微服務。
容器編排與配置管理，如何合理地實現容器編排和配置管理？
服務監控，如何有效地監控數量龐大的微服務？
故障恢復與業務調度，出現故障時如何進行業務調度？
快速擴展，由於春節紅包或直播所導致的業務爆炸式增長或觸發時，如何快速擴容？
資源的利用效率，運維人員需要思考如何在保障業務穩定發展的同時，控制好成本不會大幅增長，資源不會出現簡單堆砌。
微服務架構運維的解決之道
下面先以微信為例，講解它使用到微服務架構的地方，接著介紹我們在微服務容量管理方面的具體工作，然後給大家分享在監控部署調度上值得參考的地方，最後探討我們在資源利用率上的精細化運營。
微信為什麼要微服務雲化
自 2011 年誕生以來，微信一直強調使用快速反覆運算、試錯、糾正的敏捷開發模式，也就是我們常說的“小步快跑”方式。
在微信內部有四個“法器”，分別是：
大系統小做
讓一切可擴展
有基礎的元件
能夠輕鬆地上線
大系統小做，不僅涉及到將海量系統中的模組變得更清晰，而且在物理環境中實現分開獨立的部署，以便快速發現問題。
例如：一些公共服務的註冊登錄、LBS 的邏輯、和類似微信的搖一搖等方面，我們都將這些邏輯獨立了出來。
讓一切可擴展，此處強調兩個方面：
網路通訊協定的擴展。通過向前相容，以應對將來可能出現的升級。
資料存儲的擴展。傳統的 MySQL 之類的結構化資料存儲，對於後期頻繁增加欄位的擴展性並不方便。因此微信採用的是 Key-Value 的非結構化資料結構，以方便存儲上的擴展。
在 2013 年到 2014 年間，微信的微服務模組數已超過了 5000 個，我們碰到過兩個問題：
如果在一台硬體能力超強的伺服器上只部署一個模組，則勢必造成資源浪費。因此我們採用了混合部署，在一個伺服器上部署多個服務。
多個服務在一台伺服器上搶資源，從而影響了服務的穩定性。因此我們採用了容器隔離。
有基礎的元件，把複雜的邏輯固化下來，成為基礎性軟體。在微信的後臺會有幾種不同的基礎組件，大致包括：
Svrkit，Client/Server自動代碼生成框架，實現 10 分鐘搭建內部伺服器。
LogicServer，邏輯容器：隨時添加新邏輯。
OssAgent，監控/統計框架：所見即所得的監控報表。
存儲元件，遮罩容災/擴容等複雜問題。
微信微服務架構的應用與管理
我們對微信裡的各個微服務應用場景進行了定義：
服務佈局，就是將使用者運用不同的方法與服務維度進行“切割”和佈局。
引入各種容錯機制，如：當服務訪問中斷時，可自動重試；當服務運能不夠時，有超載保護和負載均衡；在必要時，可隨時關閉服務，實現柔性可用。
容量管理與監控。
部署管理與調度。
精細化運營。
我們對微服務也進行了技術分層：
接入層，主要實現對用戶的切分，以識別不同的運營商和不同的地域。
邏輯層，在微信中，微服務被更多地應用在邏輯層。
存儲層，主要應對海量資料，以及獨佔資源的情況。
服務佈局
微信採用多地自治、園區互備的架構，城市之間的資料是相對獨立的。除了少數帳號全球同步以外，大部分業務都以電子郵件式的服務，各自有自身的環境在流轉和通信。城市間的後備則使用公網的 UDP 通道。
在城市內，使用三園區的架構，每個園區都是一套獨立的系統，從接入、邏輯、存儲每一層都是完全獨立的，並且可以互相為對方提供備份，多園區形成整體服務規模。
在園區內，由多機組成的 set，互為容錯，包含它們的網路與電力也是獨立的。這樣的服務佈局，不僅滿足微服務架構，也考慮了容災能力。
超載保護
超載保護是一個非常核心的微服務架構特性，目的是確保核心服務可用。
它包括三個層次：
服務要有輕重分離。即一個服務裡不能既有重的操作，又有輕的操作。
佇列控制。我們通過監控，來瞭解一個請求在佇列中等待的平均時間，從而決定是否要啟動拒絕或是限流。例如：對超過設定閥值的流量進行限制，確保服務可用。
組合命令式。由於微服務的調用鏈以及層次的增多，後端服務也會有多種。假定後端有兩個服務（A 服務與 B 服務），而前端調用需要依賴於 A、B 服務的組合結果，那麼單個 A 或者單個 B 的輕微超載，就可能導致前端服務不可用。
在這種情況下，需要有一個回饋機制。如上圖所示，整個系統基於回饋，把整個拒絕的資訊全程傳遞。上圖右側是幾個典型的服務，從一個 CGI 調用一個後臺服務，再調用另一個後臺服務，系統會在 CGI 層面把它的重要程度往下傳。
回到剛才前端調用 A、B 服務的例子，使用這樣一種重要程度的傳遞，就可以直接拒絕那些相同用戶的 20% 的請求，有效地解決單個服務輕微超載的問題。
容量管理
為了在微服務架構下實行較好的容量關係，微信做到了三個前提：
微服務間資源進行隔離管理
微服務的超載有自我保護能力
服務的快速伸縮操作
容量管理是為了更好地進行業務支撐，因此我們構建了需要支撐的業務與其容量之間的模型關係，從而有效地評估出那些有效的微服務所對應的容量。
如上圖所示，下方的灰色線表示實際業務的容量，即業務量，如：請求量、調用量、以及用戶數。
紅色線表示在機器擴容或升級之後的現網容量。綠色線則表示最優容量，它比現網容量要高出 20%，以保證只是偶爾被觸發。
當業務需求超過現有容量時，業務就可能出現不穩定或者無法提供服務的情況。而擴容則往往涉及到複雜的數學運算。
因此由於現實中資源的採購、部署與上架存在週期，不大可能完全達到該綠色曲線。
隨著公有雲被廣泛地運用，我們基本上能夠實現及時獲取容量資源。當然要保證具有較好的業務支撐的話，應當具有容量的發現能力和適當的處理效率。
在實際進行容量評估的時候，可能會碰到如上圖所示的“坑點”：我們可能會將容量誤解為左邊的線性關係。
在某些時候，使用量上升到 60% 之前還是處於線性，可一旦升至 65% 或 80% 時，就會維持那麼多且再也上不去了，如右邊的容量模型所示。
所以說容量評估的困難之處就在於：一個應用或一個微服務在使用資源時會受到諸如：CPU、記憶體、網路、以及磁片 I/O 等多種因素的制約。
因此，我們應當去熟悉某個微服務主要消耗資源的關鍵點，以及它與其他資源之間的關係。
針對容量的評估，同樣在微信中引入了壓測。如圖所示，我們有四種模擬測試的方案：
模擬流量到測試環境，它對現網不產生影響。這往往由測試團隊來操作。
真實流量到測試環境，即運用 TCP 協定複製一份流量到測試環境。許多電商經常在一些大促之前，會把一些真實的流量引到測試環境之中，以檢驗系統到底能支撐多久。這往往由運維和開發協同執行。
模擬流量到現網環境，這種並不常見。
真實流量到真實環境，這是在微信中使用最多主要的現網壓測方式。該方法雖然最真實、且對容量的評估也最準確，但也會有最大的風險。它可能會引發故障，並考驗我們及時發現故障點的能力。
壓測具有雙面性，好的一面在於：有助於我們發現過去未曾注意的底層問題；不好的一面，則是在出現問題之後，我們可能無法快速地恢復，有時甚至並非將流量撤掉那麼簡單。
因為一旦某個服務崩潰了，則需要花時間和精力重新開機它。因此我們在做真實壓測時，會特別注意上圖所列的三點。
上圖展示了超載保護的機制。當有更多的流量抵達時，過剩的流量會被直接拒絕掉，顯然我們也可籍此測算出其真實的流量大小。
可見超載保護，或稱快速拒絕是在微服務架構下做好容量管理的重要前提。如果沒有該保護，將很難評估現網容量的門限。
微服務監控
微信實現了對於微服務的立體化監控，監控的內容包括：
常規指標，如 CPU、記憶體、網卡等。
快速拒絕的數量級，通過該數量級，可以進一步評估受影響的用戶量。
耗時方面的精確資料。
調用失敗的次數、重試的次數。
這些在監控上都有一些資料來上報及展現。由於我們監控指標非常多，同時伴隨著微服務的增多，其產生的報警數量也會呈爆炸式增長。因此需要有智慧化的運維，通過 AI 應用去收斂各種報警。
就監控能力而言，我們為每台機器都部署了 Agent。這些 Agent 的監控細微性比較密集，能夠達到秒級監控。與此同時，它們的資料上報能力也較為迅速。
業務部署與調度
容器的編排是微服務的一個重要方面，不同於 Docker，微信採用的是自研的 svrkit 架構，它參考了 borg/yarn/k8s/mesos 等主流調度系統的特點，該容器調度的微服務覆蓋率超過 80%。
微信的容器調度系統叫做 yard。如上圖下方所示，它分為兩層架構：
Resource Manager 和 Node Manager，負責資源管理。
Application Master 和 API/Query Server，負責作業管理。
資源管理的監控能夠決定出：在哪個容器中將哪個應用“拉起來”，而在哪個容器裡將其“下線”。
雖然該容器編排架構屬於微信自研、且尚未對外開放，但是其調度能力已逐步開放到了騰訊雲之上。
騰訊雲提供了包括集群管理、資源調度、以及鏡像倉庫等方面的結合。其對應的產品包括 CCS（容器管理）、API 閘道、以及分散式微服務的架構管理等。
微服務精細化運營
精細化運營要做到對資源進行“削峰填穀”。通過瞭解業務的特性，掌握每個業務峰值的不同時間，從而將資源盡可能控制在上圖的藍色線條附近。
例如：微信的遊戲裡有一個功能模組，在淩晨零點的時候開始新發禮品。此時該模組對於資源的需求會劇增，而同一時刻其他模組的資源消耗並不多。
因此我們就可以把該遊戲發禮品的微服務部署到其他模組伺服器資源之上，從而削除它的峰值，達到了錯峰服務的效果。
我們在許多場景中會用到離線計算，如：各種日誌分析、應用資料分析、以及人工智慧方面的訓練。
這些都是可以使用到離線計算的業務，多數不需要即時，它們都可以被部署在資源穀底的時候。
微服務的未來演進
我們採用微服務架構之後，有些問題也值得我們去認真思考：
微服務這麼多，我們能否延用以往的 CMDB 方式進 行有效地管理呢？特別是那些放在公有雲端的微服務，如何將它們納入現有的 CMDB 呢？
是否有更好的微服務管理工具，來實現服務視覺化、消息跟蹤和智慧故障檢測？
是否有微服務的應用商店，來幫助我們快速地開發各種應用？
熊普江，騰訊公司資深架構師 ，負責公司騰訊雲技術、解決方案佈道與技術架構評審等工作。騰訊公司級課程講師，GITC 專家顧問，WOT 特約講師，GOPS 金牌講師。自 1997 年涉足互聯網，曾服務美國 Supreme、太平洋網路、PPTV 等互聯網公司，任網路運營總監、運維總監等職務。近 20 年互聯網從業背景，對大型網路架構規劃與建設，海量用戶平臺規劃與運營技術支援，超大規模業務資源規劃與技術架構管理優化有豐富的經驗。
【51CTO原創稿件，合作網站轉載請注明原文作者和出處為51CTO.com】
基於上述移動互聯網時代的開發特徵，一種適用於快速變化需求的微服務架構應運而生，同時它也催生了 DevOps 的概念。
它是一種敏捷的開發模式架構，能夠讓我們迅速地實現：編寫規劃→編寫代碼→構建測試→發佈上線→部署應用。
近兩年，微服務這個術語漸成熱門詞彙，但它不是一個全新架構，更不是一個包治百病的架構。
那麼，微服務架構與單體式架構相比優勢體現在哪？這些優勢又給開發模式、運維帶來哪些挑戰？
微服務架構的特點與趨勢
微服務架構的特點與趨勢如下：
一種架構風格。微服務架構實際上並非一種新的技術或能力，而只是一種架構的風格。它大約出現在 2014 年，但是微信早在 2011 年就開始使用該架構風格和思路進行開發與運維了。
強調服務的顆粒度、敏捷性和健壯性。微服務能夠實現快速地開發、部署、和穩健地運行。
單一、獨立。微服務專注于解決單一問題，因此非常獨立。該獨立性體現在完成某個功能不依賴其他的服務，即如果該服務出錯，並不會影響到其他服務。
解耦，去中心化，元件化封裝。既然相對獨立，那麼業務之間就是一種解耦的關係。縱觀整個應用之中的各個服務，雖然重要程度有所區別，但是沒有一個服務必須以微服務為中心，因此它具有去中心化的特點。
為了能在與其他的微服務打交道時使用統一的介面，微服務也會進行各種封裝。
多個微服務組合完成相對複雜的業務系統。我們能夠快速地將各個微服務組合到一起，構建出一個能夠達到特定需求且相對複雜的業務系統。
高性能，高容錯。由於每個服務都相對獨立，就能夠在保持系統穩定的前提下，極致地追求每個微服務的性能。在分散式的結構中，單個微服務的出錯（比如硬體出現問題）不會影響到其他的微服務。
另外在多個微服務並存時，同一個服務會有多個正在運行當副本，因此具有高容錯性。
微服務架構解析
微服務架構解析：
適用於構建複雜的應用，通過運用微服務，可以將各種模組如搭積木一般組合成相對複雜的應用。
分散式，由於各個微服務之間都遵守相同的協議，可以實現多個微服務的分散式部署。
分別部署，由於每個微服務都具有單一且獨立的功能，因此服務模組的數量顯然是龐大的，光靠人工完全無法實現分開部署。隨著微服務的數量呈幾何基數增長，我們需要用一套自動化的工具來進行快速地部署。
服務元件，微服務一般分為兩種不同的類別：一是基礎模組或稱公共模組。如：使用者登錄、推送（Push）服務模組；另一是功能性模組，如：實現發消息或發朋友圈的模組。
微服務的邊界，雖然用的是同一種語言，但是可以進行獨立地開發與測試，因此每個微服務在被發佈的時候不會跟其他的微服務共用資料存儲或記憶體空間。每個微服務都有自己的獨立空間。
API 層，如上圖所示，微服務與外界有一個介面層，它們遵守共同的協議進行通信，如 RPC 或 Restful 等，大家可以自由選擇各種技術。
微服務架構的擴展，為了應對未來可能對現有微服務的功能性增加，或是要增加其他業務場景，我們一般不在原有微服務上著手增加，而是新建另一個微服務，並獨立部署。
微服務架構的優勢
微服務架構有如下幾個明顯的優勢：
單個微服務更易理解，方便開發與維護。相比以往，只要定義好了一個微服務，我們在開發、維護和部署時就能方便地理解其功能意圖。
應用解耦、對應用整體應用交付而言，開發反覆運算更敏捷。我們可以單獨對一個微服務進行升級，而不會影響其他微服務的功能。
技術選擇更加自由，微服務不再需要限定某個統一的技術實現。每個程式師都有自己的技術偏好，有人喜歡 Java，也有人喜歡 PHP 或是 C。
以往大家不得不根據統一技術框架，遵循一致的開發語言。如今每個微服務都可以用不同的語言來實現。
微服務獨立部署，應用更穩定。由於每個微服務都不影響其他的微服務，因此單獨部署會給整體應用帶來更好的穩定性。
架構擴展更容易、更快速。如右圖所示，我們從三個維度進行架構設計。其中 X 軸表示可以放置多個副本；Y 軸是通過分層來擴容服務；而 Z 軸是對服務進行資料分區。
這說明我們的微服務能從 X、Y、Z 三個方向去擴展整體架構。
微服務架構帶來的挑戰
下面是談談引入微服務架構時會碰到的各種挑戰：
開發模式需要相應調整，首先要從“縱切”的開發思維轉變成“橫切”的思維。
跟以往相比，微服務的數量會大幅增加。
資料增多導致了容器的編排、配置與資源的管理更為複雜。相對于過去只需管幾台機器而言，如今如何搭配和配置各種微服務會變得更複雜。
業務的容量管理變得更加困難，資源利用效率難以提升。以前我們只需要監控某幾台機器的使用率。
如今，由於容器存在多台伺服器上，就需要對容器裡各種服務的資源利用率和容量進行綜合管理，同時對它們的提升難度也更大了。
監控的顆粒度增多，依賴及關聯關係更加複雜。由於微服務的增多，監控的顆粒也相應有所增加。如上圖右側所示，顆粒之間的關聯關係也會變得更加複雜。
在微服務出現故障時，我們要有快速調度的能力，因此調度需要更精細化。
微服務架構下的運維思考
下面是我在微服務架構下的一些運維思考：
容量管理，即：如何在細細微性的狀態下，更有效地管理數量龐大的微服務。
容器編排與配置管理，如何合理地實現容器編排和配置管理？
服務監控，如何有效地監控數量龐大的微服務？
故障恢復與業務調度，出現故障時如何進行業務調度？
快速擴展，由於春節紅包或直播所導致的業務爆炸式增長或觸發時，如何快速擴容？
資源的利用效率，運維人員需要思考如何在保障業務穩定發展的同時，控制好成本不會大幅增長，資源不會出現簡單堆砌。
微服務架構運維的解決之道
下面先以微信為例，講解它使用到微服務架構的地方，接著介紹我們在微服務容量管理方面的具體工作，然後給大家分享在監控部署調度上值得參考的地方，最後探討我們在資源利用率上的精細化運營。
微信為什麼要微服務雲化
自 2011 年誕生以來，微信一直強調使用快速反覆運算、試錯、糾正的敏捷開發模式，也就是我們常說的“小步快跑”方式。
在微信內部有四個“法器”，分別是：
大系統小做
讓一切可擴展
有基礎的元件
能夠輕鬆地上線
大系統小做，不僅涉及到將海量系統中的模組變得更清晰，而且在物理環境中實現分開獨立的部署，以便快速發現問題。
例如：一些公共服務的註冊登錄、LBS 的邏輯、和類似微信的搖一搖等方面，我們都將這些邏輯獨立了出來。
讓一切可擴展，此處強調兩個方面：
網路通訊協定的擴展。通過向前相容，以應對將來可能出現的升級。
資料存儲的擴展。傳統的 MySQL 之類的結構化資料存儲，對於後期頻繁增加欄位的擴展性並不方便。因此微信採用的是 Key-Value 的非結構化資料結構，以方便存儲上的擴展。
在 2013 年到 2014 年間，微信的微服務模組數已超過了 5000 個，我們碰到過兩個問題：
如果在一台硬體能力超強的伺服器上只部署一個模組，則勢必造成資源浪費。因此我們採用了混合部署，在一個伺服器上部署多個服務。
多個服務在一台伺服器上搶資源，從而影響了服務的穩定性。因此我們採用了容器隔離。
有基礎的元件，把複雜的邏輯固化下來，成為基礎性軟體。在微信的後臺會有幾種不同的基礎組件，大致包括：
Svrkit，Client/Server自動代碼生成框架，實現 10 分鐘搭建內部伺服器。
LogicServer，邏輯容器：隨時添加新邏輯。
OssAgent，監控/統計框架：所見即所得的監控報表。
存儲元件，遮罩容災/擴容等複雜問題。
微信微服務架構的應用與管理
我們對微信裡的各個微服務應用場景進行了定義：
服務佈局，就是將使用者運用不同的方法與服務維度進行“切割”和佈局。
引入各種容錯機制，如：當服務訪問中斷時，可自動重試；當服務運能不夠時，有超載保護和負載均衡；在必要時，可隨時關閉服務，實現柔性可用。
容量管理與監控。
部署管理與調度。
精細化運營。
我們對微服務也進行了技術分層：
接入層，主要實現對用戶的切分，以識別不同的運營商和不同的地域。
邏輯層，在微信中，微服務被更多地應用在邏輯層。
存儲層，主要應對海量資料，以及獨佔資源的情況。
服務佈局
微信採用多地自治、園區互備的架構，城市之間的資料是相對獨立的。除了少數帳號全球同步以外，大部分業務都以電子郵件式的服務，各自有自身的環境在流轉和通信。城市間的後備則使用公網的 UDP 通道。
在城市內，使用三園區的架構，每個園區都是一套獨立的系統，從接入、邏輯、存儲每一層都是完全獨立的，並且可以互相為對方提供備份，多園區形成整體服務規模。
在園區內，由多機組成的 set，互為容錯，包含它們的網路與電力也是獨立的。這樣的服務佈局，不僅滿足微服務架構，也考慮了容災能力。
超載保護
超載保護是一個非常核心的微服務架構特性，目的是確保核心服務可用。
它包括三個層次：
服務要有輕重分離。即一個服務裡不能既有重的操作，又有輕的操作。
佇列控制。我們通過監控，來瞭解一個請求在佇列中等待的平均時間，從而決定是否要啟動拒絕或是限流。例如：對超過設定閥值的流量進行限制，確保服務可用。
組合命令式。由於微服務的調用鏈以及層次的增多，後端服務也會有多種。假定後端有兩個服務（A 服務與 B 服務），而前端調用需要依賴於 A、B 服務的組合結果，那麼單個 A 或者單個 B 的輕微超載，就可能導致前端服務不可用。
在這種情況下，需要有一個回饋機制。如上圖所示，整個系統基於回饋，把整個拒絕的資訊全程傳遞。上圖右側是幾個典型的服務，從一個 CGI 調用一個後臺服務，再調用另一個後臺服務，系統會在 CGI 層面把它的重要程度往下傳。
回到剛才前端調用 A、B 服務的例子，使用這樣一種重要程度的傳遞，就可以直接拒絕那些相同用戶的 20% 的請求，有效地解決單個服務輕微超載的問題。
容量管理
為了在微服務架構下實行較好的容量關係，微信做到了三個前提：
微服務間資源進行隔離管理
微服務的超載有自我保護能力
服務的快速伸縮操作
容量管理是為了更好地進行業務支撐，因此我們構建了需要支撐的業務與其容量之間的模型關係，從而有效地評估出那些有效的微服務所對應的容量。
如上圖所示，下方的灰色線表示實際業務的容量，即業務量，如：請求量、調用量、以及用戶數。
紅色線表示在機器擴容或升級之後的現網容量。綠色線則表示最優容量，它比現網容量要高出 20%，以保證只是偶爾被觸發。
當業務需求超過現有容量時，業務就可能出現不穩定或者無法提供服務的情況。而擴容則往往涉及到複雜的數學運算。
因此由於現實中資源的採購、部署與上架存在週期，不大可能完全達到該綠色曲線。
隨著公有雲被廣泛地運用，我們基本上能夠實現及時獲取容量資源。當然要保證具有較好的業務支撐的話，應當具有容量的發現能力和適當的處理效率。
在實際進行容量評估的時候，可能會碰到如上圖所示的“坑點”：我們可能會將容量誤解為左邊的線性關係。
在某些時候，使用量上升到 60% 之前還是處於線性，可一旦升至 65% 或 80% 時，就會維持那麼多且再也上不去了，如右邊的容量模型所示。
所以說容量評估的困難之處就在於：一個應用或一個微服務在使用資源時會受到諸如：CPU、記憶體、網路、以及磁片 I/O 等多種因素的制約。
因此，我們應當去熟悉某個微服務主要消耗資源的關鍵點，以及它與其他資源之間的關係。
針對容量的評估，同樣在微信中引入了壓測。如圖所示，我們有四種模擬測試的方案：
模擬流量到測試環境，它對現網不產生影響。這往往由測試團隊來操作。
真實流量到測試環境，即運用 TCP 協定複製一份流量到測試環境。許多電商經常在一些大促之前，會把一些真實的流量引到測試環境之中，以檢驗系統到底能支撐多久。這往往由運維和開發協同執行。
模擬流量到現網環境，這種並不常見。
真實流量到真實環境，這是在微信中使用最多主要的現網壓測方式。該方法雖然最真實、且對容量的評估也最準確，但也會有最大的風險。它可能會引發故障，並考驗我們及時發現故障點的能力。
壓測具有雙面性，好的一面在於：有助於我們發現過去未曾注意的底層問題；不好的一面，則是在出現問題之後，我們可能無法快速地恢復，有時甚至並非將流量撤掉那麼簡單。
因為一旦某個服務崩潰了，則需要花時間和精力重新開機它。因此我們在做真實壓測時，會特別注意上圖所列的三點。
上圖展示了超載保護的機制。當有更多的流量抵達時，過剩的流量會被直接拒絕掉，顯然我們也可籍此測算出其真實的流量大小。
可見超載保護，或稱快速拒絕是在微服務架構下做好容量管理的重要前提。如果沒有該保護，將很難評估現網容量的門限。
微服務監控
微信實現了對於微服務的立體化監控，監控的內容包括：
常規指標，如 CPU、記憶體、網卡等。
快速拒絕的數量級，通過該數量級，可以進一步評估受影響的用戶量。
耗時方面的精確資料。
調用失敗的次數、重試的次數。
這些在監控上都有一些資料來上報及展現。由於我們監控指標非常多，同時伴隨著微服務的增多，其產生的報警數量也會呈爆炸式增長。因此需要有智慧化的運維，通過 AI 應用去收斂各種報警。
就監控能力而言，我們為每台機器都部署了 Agent。這些 Agent 的監控細微性比較密集，能夠達到秒級監控。與此同時，它們的資料上報能力也較為迅速。
業務部署與調度
容器的編排是微服務的一個重要方面，不同於 Docker，微信採用的是自研的 svrkit 架構，它參考了 borg/yarn/k8s/mesos 等主流調度系統的特點，該容器調度的微服務覆蓋率超過 80%。
微信的容器調度系統叫做 yard。如上圖下方所示，它分為兩層架構：
Resource Manager 和 Node Manager，負責資源管理。
Application Master 和 API/Query Server，負責作業管理。
資源管理的監控能夠決定出：在哪個容器中將哪個應用“拉起來”，而在哪個容器裡將其“下線”。
雖然該容器編排架構屬於微信自研、且尚未對外開放，但是其調度能力已逐步開放到了騰訊雲之上。
騰訊雲提供了包括集群管理、資源調度、以及鏡像倉庫等方面的結合。其對應的產品包括 CCS（容器管理）、API 閘道、以及分散式微服務的架構管理等。
微服務精細化運營
精細化運營要做到對資源進行“削峰填穀”。通過瞭解業務的特性，掌握每個業務峰值的不同時間，從而將資源盡可能控制在上圖的藍色線條附近。
例如：微信的遊戲裡有一個功能模組，在淩晨零點的時候開始新發禮品。此時該模組對於資源的需求會劇增，而同一時刻其他模組的資源消耗並不多。
因此我們就可以把該遊戲發禮品的微服務部署到其他模組伺服器資源之上，從而削除它的峰值，達到了錯峰服務的效果。
我們在許多場景中會用到離線計算，如：各種日誌分析、應用資料分析、以及人工智慧方面的訓練。
這些都是可以使用到離線計算的業務，多數不需要即時，它們都可以被部署在資源穀底的時候。
微服務的未來演進
我們採用微服務架構之後，有些問題也值得我們去認真思考：
微服務這麼多，我們能否延用以往的 CMDB 方式進 行有效地管理呢？特別是那些放在公有雲端的微服務，如何將它們納入現有的 CMDB 呢？
是否有更好的微服務管理工具，來實現服務視覺化、消息跟蹤和智慧故障檢測？
是否有微服務的應用商店，來幫助我們快速地開發各種應用？
熊普江，騰訊公司資深架構師 ，負責公司騰訊雲技術、解決方案佈道與技術架構評審等工作。騰訊公司級課程講師，GITC 專家顧問，WOT 特約講師，GOPS 金牌講師。自 1997 年涉足互聯網，曾服務美國 Supreme、太平洋網路、PPTV 等互聯網公司，任網路運營總監、運維總監等職務。近 20 年互聯網從業背景，對大型網路架構規劃與建設，海量用戶平臺規劃與運營技術支援，超大規模業務資源規劃與技術架構管理優化有豐富的經驗。
【51CTO原創稿件，合作網站轉載請注明原文作者和出處為51CTO.com】