【51CTO.com原創(chuàng)稿件】2017 年 12 月 01 日-02 日，由 51CTO 主辦的WOTD 全球軟件開發(fā)技術峰會將在深圳中州萬豪酒店隆重舉行。本次峰會以軟件開發(fā)為主題，數十位專家級嘉賓將帶來多場精彩的技術內容分享。屆時，熊普江先生將在“微服務與容器技術”專場與來賓分享"云端微服務架構的運維思考"的主題演講。熊普江先生將會為大家詳細闡述“微服務架構的特點與發(fā)展趨勢，結合微信業(yè)務在微服務架構上的探索、應用、改進與提升，分析運維如何應對業(yè)務在微服務架構環(huán)境下的各種挑戰(zhàn)。”51CTO 誠邀您蒞臨大會，與我們共享技術帶來的喜悅。

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

從圖中可以看出，自 2013 前后微服務開始逐漸被人關注，隨時間推移搜索的人也越來越多，直至 2016 年爆發(fā)。

微服務架構的快速發(fā)展并廣泛流行，和以下因素息息相關：

• 互聯網技術架構飛速演進，特別是底層硬件及芯片技術快速發(fā)展，后端服務器的能力越來越強大。多數情況下，單個業(yè)務已很難消耗完一整臺服務器的資源或處理能力。
• 移動互聯網深度融合與應用，瘦客戶端興起，使得云端能力與承載變得更加重要。
• 容器技術得到廣泛認可與應用，輕量級協議、代碼管理、新集成方法與工具等技術也越來越成熟。

近兩年，微服務這個術語漸成熱門詞匯，但它不是一個全新架構，更不是一個包治百病的架構。那么，微服務架構與單體式架構相比優(yōu)勢體現在哪？這些優(yōu)勢又給開發(fā)模式、運維帶來哪些痛點？

微服務架構的優(yōu)勢及痛點

微服務和單點服務的區(qū)別是什么呢？比喻來講，單點服務是把所有的東西放在一個大盒子里，這個大盒子里什么都有。微服務更像是車箱，每個箱子里包含特定的功能模塊和物品，所有東西可以很靈活地拆分出來。換言之，在單點服務中，所有的部件都在一個巨大的軟件包中。在微服務架構下，有很多獨立存在的小服務，通過 API 接口連接成龐大的系統(tǒng)。

相比過往的單體式應用架構，微服務架構優(yōu)勢明顯，如：

• 單個微服務更易理解、方便開發(fā)與維護。
• 應用解耦，對應用整體應用交付而言，開發(fā)迭代更敏捷。
• 技術選擇更加自由，微服務不再需要限定統(tǒng)一的技術實現。
• 微服務獨立部署，應用更穩(wěn)定，同時擴展更加容易與快速。
• ……

同時，微服務架構的特點與優(yōu)勢在開發(fā)模式、運維等方面也帶來很多痛點，如：

• 微服務眾多，容器編排與部署管理等會變得異常復雜。
• 業(yè)務的容量管理變得更加困難，資源利用效率難以提升。
• 監(jiān)控的顆粒度增多，關聯關系更加復雜。
• 微服務故障恢復、調度需要更精細化。
•  ……

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

熊普江老師表示，微信一直提倡敏捷開發(fā)與“大系統(tǒng)小做”，這其實就是微服務的理念與架構實現。

由于微信誕生于 2011 年，當時微服務架構的概念還沒有出來，也就是說，微信的微服務架構在業(yè)界實施并落地相對較早。

微信中微服務案例有很多，這里主要分享服務布局、過載保護兩大典型案例。

服務布局

微信的服務布局采用的是多地自治、園區(qū)互備架構。如下，是微信的服務布局示意圖：

    城市之間的數據是相對獨立的。除了少數賬號全球同步，大部分業(yè)務都希望做成電子郵件式的服務，各自有自身的環(huán)境在跑，之間使用類似于電子郵件的通信。

    城市間的后備則使用公網的 udp 通道。在城市內，使用三園區(qū)架構，每個園區(qū)是一套獨立的系統(tǒng)，從接入、邏輯、存儲每一層完全獨立，可互相為對方提供備份。

    多園區(qū)形成整體服務能力。在園區(qū)內，由多機組成 set，互為容錯，包含網絡與電力也是獨立的。這樣的服務布局，不僅是微服務架構，而且是考慮了容災能力。

過載保護

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

• 考慮問題應該是服務要有輕重分離，即一個服務里不能既有重的操作，又有輕的操作。
• 隊列控制，要了解一個請求在隊列中待的平均時間，從而決定是否要啟動拒絕；
• 組合命令式，由于微服務的調用鏈及層次可能會增多，后端服務也可能是多個。

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

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

如上圖中所示，整個系統(tǒng)基于反饋，并把整個拒絕的信息全程傳遞。最右邊，是幾個典型的服務，從一個 CGI 調用一個后臺服務，再調用另一個后臺服務，系統(tǒng)會在 CGI 層面就把它的重要程度往下傳。

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

寫在***

如果您想了解更多更詳細的內容，如隨業(yè)務的發(fā)展，在微服務架構要做了哪些調整或研發(fā)、運維方面是如何布設的、過程中有遇到哪些難點以及技術團隊又是怎樣應對的！歡迎各位小伙伴來到 WOTD 峰會現場，聆聽熊普江老師的精彩演講。

使用優(yōu)惠碼[2017WOTDSZ]，和我一起去WOTD全球軟件開發(fā)技術峰會。8折優(yōu)惠，僅剩48小時!

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