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

互聯(lián)網(wǎng)技術(shù)一直在快速演進(jìn)當(dāng)中，同時(shí)移動(dòng)互聯(lián)網(wǎng)與云時(shí)代來臨，微服務(wù)架構(gòu)由此應(yīng)映而生。如下圖，是微服務(wù)在我國(guó)的百度搜索指數(shù)：

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

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

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

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

微服務(wù)架構(gòu)的優(yōu)勢(shì)及痛點(diǎn)

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

相比過往的單體式應(yīng)用架構(gòu)，微服務(wù)架構(gòu)優(yōu)勢(shì)明顯，如：

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

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

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

微信中兩大典型微服務(wù)案例

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

由于微信誕生于 2011 年，當(dāng)時(shí)微服務(wù)架構(gòu)的概念還沒有出來，也就是說，微信的微服務(wù)架構(gòu)在業(yè)界實(shí)施并落地相對(duì)較早。

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

服務(wù)布局

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

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

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

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

過載保護(hù)

過載保護(hù)的微服務(wù)架構(gòu)，目的是確保核心服務(wù)可用。確保核心服務(wù)的可用性有如下三點(diǎn)：

• 考慮問題應(yīng)該是服務(wù)要有輕重分離，即一個(gè)服務(wù)里不能既有重的操作，又有輕的操作。
• 隊(duì)列控制，要了解一個(gè)請(qǐng)求在隊(duì)列中待的平均時(shí)間，從而決定是否要啟動(dòng)拒絕；
• 組合命令式，由于微服務(wù)的調(diào)用鏈及層次可能會(huì)增多，后端服務(wù)也可能是多個(gè)。

假定后端有兩個(gè)服務(wù)（A 服務(wù)與 B 服務(wù)），而前端調(diào)用需要依賴于 A、B 服務(wù)的組合結(jié)果，那么單個(gè) A 或者單個(gè) B 的輕微過載，就可能導(dǎo)致前端服務(wù)不可用，這是很嚴(yán)重的問題。這種情況下，就需要一個(gè)反饋機(jī)制。

如下，是過載保護(hù)的微服務(wù)架構(gòu)示意圖：

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

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

寫在***

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

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

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