騰訊公資深架構師解析微信如何使用微服務架構案例（服務佈局、過載保護）

互聯網技術一直在快速演進當中，同時移動互聯網與雲時代來臨，微服務架構由此應映而生。
以下圖，是微服務在我國的百度搜索指數：

從圖中能夠看出，自 2013 先後微服務開始逐漸被你們關注，隨時間推移搜索的人也愈來愈多，直至 2016 年爆發。

微服務架構的快速發展並普遍流行，和如下因素息息相關：

1.互聯網技術架構飛速演進，特別是底層硬件及芯片技術快速發展，後端服務器的能力愈來愈強大。多數狀況下，單個業務已很難消耗完一整臺服務器的資源或處理能力。

2.移動互聯網深度融合與應用，瘦客戶端興起，使得雲端能力與承載變得更加劇要。

3.容器技術獲得普遍承認與應用，輕量級協議、代碼管理、新集成方法與工具等技術也愈來愈成熟。

近兩年，微服務這個術語漸成熱門詞彙，但它不是一個全新架構，更不是一個包治百病的架構。那麼，微服務架構與單體式架構相比優點體如今哪？這些優點又給開發模式、運維帶來哪些痛點？

微服務架構的優點及痛點

微服務和單點服務的區別是什麼呢？比喻來說，單點服務是把全部的東西放在一個大盒子裏，這個大盒子裏什麼都有。

微服務更像是車廂，每一個箱子裏包含特定的功能模塊和物品，全部模塊能夠很靈活地拆分出來。

換言之，在單點服務中，全部的部件都在一個巨大的軟件包中。在微服務架構下，有不少獨立存在的小服務，經過 API 接口鏈接成龐大的系統。

相比過往的單體式應用架構，微服務架構優點明顯，如：

單個微服務更易理解、方便開發與維護。

應用解耦，對總體應用交付而言，開發迭代更敏捷。

技術選擇更加自由，微服務再也不須要限定統一的技術實現。

微服務獨立部署，應用更穩定，同時擴展更加容易與快速。

……

同時，微服務架構的特色與優點在開發模式、運維等方面也帶來不少痛點，如：

微服務衆多，容器編排與部署管理等會變得異常複雜。

業務的容量管理變得更加困難，資源利用效率難以提高。

監控的顆粒度增多，關聯關係更加複雜。

微服務故障恢復、調度須要更精細化。

推薦一個交流學習羣：478030634 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

微信中兩大典型微服務案例

微信一直提倡敏捷開發與「大系統小作」，這其實就是微服務的理念與架構實現。

因爲微信誕生於 2011 年，當時微服務架構的概念尚未普及，也就是說，微信的微服務架構在業界實施並落地相對較早。

微信中微服務案例有不少，這裏主要分享服務佈局、過載保護兩大典型案例。

01 服務佈局

微信的服務佈局採用的是多地自治、園區互備架構。以下，是微信的服務佈局示意圖：

城市之間的數據是相對獨立的。除了少數帳號全球同步，大部分業務都但願作成電子郵件式的服務，各自有自身的環境在跑，之間使用相似於電子郵件的通訊。

城市間的後備則使用公網的 udp 通道。在城市內，使用三園區架構，每一個園區是一套獨立的系統，從接入、邏輯、存儲每一層徹底獨立，可互相爲對方提供備份。

多園區造成總體服務能力。在園區內，由多機組成 set，互爲容錯，包含網絡與電力也是獨立的。這樣的服務佈局，不只是微服務架構，並且考慮了容災能力。

02 過載保護

過載保護的微服務架構，目的是確保核心服務可用。確保核心服務的可用性有以下三點：

考慮問題應該是服務要有輕重分離，即一個服務裏不能既有重的操做，又有輕的操做。

隊列控制，要了解一個請求在隊列中等待的平均時間，從而決定是否要啓動拒絕。

組合命令式，因爲微服務的調用鏈及層次可能會增多，後端服務也多是多個。

假定後端有兩個服務（A 服務與 B 服務），而前端調用須要依賴於 A、B 服務的組合結果，那麼單個 A 或者單個 B 的輕微過載，就可能致使前端服務不可用，這是很嚴重的問題。這種狀況下，就須要一個反饋機制。

以下，是過載保護的微服務架構示意圖：

如上圖所示，整個系統基於反饋，把整個拒絕的信息全程傳遞。最右邊是幾個典型的服務，從一個 CGI 調用一個後臺服務，再調用另外一個後臺服務，系統會在 CGI 層面就把它的重要程度往下傳。回到剛纔前端調用 A、B 服務的例子，使用這樣的一種重要程度傳遞，就能夠直接拒絕那些相同用戶的 20% 的請求，有效地解決單個服務輕微過載的問題。