起點(diǎn)

首先，我們得有一個(gè)“服務(wù)”。根據(jù)定義，我們可以把每個(gè)服務(wù)實(shí)例都視作一個(gè)黑盒。這個(gè)盒子有著明確的輸入點(diǎn)和輸出點(diǎn)，并且(理想情況下)僅通過這些輸入和輸出點(diǎn)和外界產(chǎn)生關(guān)聯(lián)。每個(gè)服務(wù)實(shí)例會(huì)擁有專屬的網(wǎng)絡(luò)地址、獨(dú)立的計(jì)算資源，并且獨(dú)立部署?？蛻舳送ㄟ^訪問服務(wù)實(shí)例的地址來調(diào)用服務(wù) API。不同服務(wù)也可以相互調(diào)用。

配置管理器：統(tǒng)一管理配置

在微服務(wù)體系中，每個(gè)服務(wù)都獨(dú)立部署和運(yùn)行，團(tuán)隊(duì)可以根據(jù)需要自行選擇增加和減少計(jì)算資源。一個(gè)服務(wù)可能會(huì)跑多個(gè)實(shí)例，每個(gè)服務(wù)實(shí)例都會(huì)需要做配置。為了方便統(tǒng)一調(diào)整配置，我們可以把配置中心化，每個(gè)服務(wù)實(shí)例都去找配置管理器(Configuration Manager)拿配置。當(dāng)配置更新的時(shí)候，我們也可以讓服務(wù)實(shí)例再去拿新的配置。

服務(wù)名冊(cè)：解耦主機(jī)地址

這也引出了一個(gè)問題：網(wǎng)絡(luò)地址(比如 IP)很容易因?yàn)閿U(kuò)容、維護(hù)而變動(dòng)，調(diào)用者難以實(shí)時(shí)獲知可用的地址。

鑒于此，我們可以把網(wǎng)絡(luò)地址抽象成不容易變動(dòng)的概念，比如給每個(gè)服務(wù)一個(gè)固定的名字。互聯(lián)網(wǎng)使用 DNS 來解決這個(gè)問題，對(duì)應(yīng)到微服務(wù)基建里面就是服務(wù)名冊(cè)(Service Registry)。

每個(gè)服務(wù)實(shí)例在運(yùn)行期間，都會(huì)以心跳的形式向服務(wù)名冊(cè)發(fā)送注冊(cè)信息，包括服務(wù)的 ID 、訪問地址以及健康狀況。這樣，需要訪問服務(wù)的時(shí)候，客戶端就可以先問服務(wù)名冊(cè)拿可用的實(shí)例地址，然后再訪問實(shí)例來調(diào)用服務(wù)。除了更好地定位實(shí)例地址，服務(wù)名冊(cè)還可以在某些實(shí)例下線、維護(hù)或升級(jí)的時(shí)候把其臨時(shí)從名冊(cè)中去掉，讓服務(wù)不斷線。

服務(wù)之間的調(diào)用也是如此，先找名冊(cè)拿網(wǎng)絡(luò)地址，再進(jìn)行調(diào)用。

API 網(wǎng)關(guān)：入口和路由

找名冊(cè)要地址，然后調(diào)用服務(wù) API，這些是每個(gè)客戶端都會(huì)去做的瑣事，我們完全可以把這些事情抽象、集中，把服務(wù)的 API 整合到一個(gè)大的中心點(diǎn)，然后把要地址和調(diào)用服務(wù) API 這樣的細(xì)節(jié)封裝起來，所有客戶端都只跟這個(gè)中心點(diǎn)對(duì)話，不再直接訪問單個(gè)服務(wù)。

從結(jié)構(gòu)上看，這個(gè)中心點(diǎn)把整個(gè)架構(gòu)劃分成了內(nèi)外兩部分，內(nèi)部是所有的服務(wù)，客戶端則在外部，中心點(diǎn)站在中間。它作為內(nèi)外的唯一通道，被順理成章地命名作“API 網(wǎng)關(guān)”(API Gateway)，有時(shí)候也被稱做“邊緣服務(wù)”(Edge Service)。

API 網(wǎng)關(guān)作為唯一出入口，又占據(jù)了最前沿的有利位置，所以有時(shí)還會(huì)承載別的公共功能，比如我們馬上會(huì)提到的鑒權(quán)。

鑒權(quán)服務(wù)：身份和權(quán)限問題

順著這個(gè)架構(gòu)繼續(xù)開發(fā)，我們會(huì)遇到新的問題：不方便的鑒權(quán)。

鑒權(quán)(Auth)包括了兩個(gè)部分：身份認(rèn)證(Authentication)和權(quán)限驗(yàn)證(Authorization)。身份認(rèn)證關(guān)心的是“你是誰”，權(quán)限驗(yàn)證關(guān)心的是“你能不能做某件事”。

身份和權(quán)限都是高度中心化的概念。

對(duì)于一個(gè)系統(tǒng)來說，用戶的身份必須是統(tǒng)一的。不能說這個(gè)用戶在做這個(gè)事情的時(shí)候是張三，做那個(gè)事情的時(shí)候是李四。此外，用戶的認(rèn)證狀態(tài)也應(yīng)該是統(tǒng)一的。不能說用戶訪問這個(gè)服務(wù)的時(shí)候是已登錄認(rèn)證，訪問另一個(gè)服務(wù)時(shí)又是未登錄狀態(tài)。所以，只能有一個(gè)身份認(rèn)證方。

權(quán)限稍微復(fù)雜一點(diǎn)。和身份不同，權(quán)限通常分成兩種類別：功能權(quán)限和數(shù)據(jù)權(quán)限。這樣的劃分對(duì)應(yīng)了現(xiàn)實(shí)世界中常見的權(quán)限模式：你的角色決定了你的職能，而職能范圍通常由附加條件來限制。比如，你是一個(gè)法官，對(duì)案件有裁決權(quán)，但是你是 A 區(qū)的法官，只能判 A 區(qū)的案子。再比如，某個(gè)快餐門店的經(jīng)理有權(quán)看員工的詳細(xì)資料，但是只能看自己門店的員工資料。

兩種權(quán)限都由全局的規(guī)則來確定，而不掌握在執(zhí)行部門。比如，誰來判案，取決于法律，而不取決于法院。誰能查看誰的資料，也不由資料保管部門決定，而由規(guī)章制度決定。

在現(xiàn)實(shí)的情況中，組織可能會(huì)有專門的審核部門來驗(yàn)證權(quán)限，但對(duì)那些不是特別敏感的權(quán)限，企業(yè)會(huì)讓各個(gè)部門自行驗(yàn)證。不過不管誰來執(zhí)行驗(yàn)證，都必須拿著同一份規(guī)章制度，不能各說各話。這份制度必須由中心機(jī)構(gòu)來統(tǒng)一制定、維護(hù)。也就是說，權(quán)限的管理也應(yīng)該中心化。

明確鑒權(quán)中心化之后，我們就可以開發(fā)一個(gè)公用的鑒權(quán)服務(wù)，執(zhí)行身份認(rèn)證和權(quán)限驗(yàn)證。下一個(gè)問題是：誰來發(fā)起鑒權(quán)?

所有服務(wù)的調(diào)用都要求調(diào)用者明確自己的身份，所以自然身份認(rèn)證越靠前越好。作為出入口的 API 網(wǎng)關(guān)自然是發(fā)起身份認(rèn)證的不二之選。權(quán)限驗(yàn)證則稍微復(fù)雜，完全值得另起一文詳述。此處我們暫時(shí)假定權(quán)限驗(yàn)證也由 API 網(wǎng)關(guān)來發(fā)起。

消息中介：異步和通知

開發(fā)繼續(xù)進(jìn)行，一切風(fēng)平浪靜，技術(shù)上暫時(shí)沒有什么問題。不過，業(yè)務(wù)上有一個(gè)問題需要解決。

比如，我們做一個(gè)在線商城，要求在訂單成功創(chuàng)建的一刻，倉庫就要啟動(dòng)備貨和發(fā)貨的流程。問題是，訂單和倉儲(chǔ)是兩個(gè)服務(wù)，不同團(tuán)隊(duì)在負(fù)責(zé)，而且從關(guān)注點(diǎn)來說，訂單服務(wù)并不關(guān)心倉儲(chǔ)相關(guān)的問題，所以訂單服務(wù)不可能在創(chuàng)建訂單的時(shí)候去主動(dòng)通知倉儲(chǔ)服務(wù)。倉儲(chǔ)服務(wù)只能定時(shí)輪詢訂單服務(wù)，看看有沒有新的訂單。這不僅麻煩，而且實(shí)時(shí)性不夠。

仔細(xì)想想，我們會(huì)發(fā)現(xiàn)這種需求很常見，信息的產(chǎn)生者并不知道(也不關(guān)心)誰會(huì)對(duì)信息產(chǎn)生興趣。比如我們可能會(huì)有一個(gè)監(jiān)控服務(wù)需要實(shí)時(shí)展示產(chǎn)品銷量，有一個(gè) BI 服務(wù)需要獲取客戶購買產(chǎn)品的信息來做分析，等等。既然這是一個(gè)常見需求，我們不妨把它模式化，形成一個(gè)機(jī)制：信息產(chǎn)生者把通知發(fā)出來，收到通知的人再確定是否需要采取行動(dòng)。

這就意味著我們需要再引入一個(gè)中心化的公共服務(wù)：消息中介(Message Broker)。當(dāng)某個(gè)事件發(fā)生的時(shí)候(比如用戶激活成功、訂單創(chuàng)建成功)，服務(wù)可以朝消息隊(duì)列發(fā)一條消息。而其他服務(wù)可以訂閱這些消息，并針對(duì)這些消息做出反應(yīng)。

比如，倉儲(chǔ)服務(wù)可以訂閱訂單創(chuàng)建成功的消息。這樣，訂單成功創(chuàng)建后，訂單服務(wù)將這個(gè)消息發(fā)到消息中介，消息中介通知倉儲(chǔ)服務(wù)，倉儲(chǔ)服務(wù)一看，就問訂單服務(wù)要新的訂單信息，***，啟動(dòng)出庫流程。

消息中介除了能廣播事件之外，還能做異步調(diào)用。把同步的調(diào)用轉(zhuǎn)化成異步的回調(diào)。針對(duì)調(diào)用時(shí)間長(zhǎng)和不要求實(shí)時(shí)結(jié)果的調(diào)用，可以增加性能，提升體驗(yàn)。

前置后端：優(yōu)化前端開發(fā)

走到這里，其實(shí)體系已經(jīng)比較完備。現(xiàn)在的問題是，如何讓微服務(wù)基建結(jié)構(gòu)和研發(fā)團(tuán)隊(duì)常見的結(jié)構(gòu)更好地對(duì)應(yīng)起來。這要求我們從康威定律的角度來看待整個(gè)基建的設(shè)計(jì)。

在圍繞用戶和價(jià)值的軟件研發(fā)流程中，我們常用用戶歷程和用戶故事來捕捉和跟蹤價(jià)值的實(shí)現(xiàn)。一個(gè)用戶故事通常會(huì)包含一個(gè)有明確邊界、明確驗(yàn)收標(biāo)準(zhǔn)和明確價(jià)值的業(yè)務(wù)步驟。

問題在于，支撐一個(gè)故事有前后兩端的研發(fā)工作，二者是不同步的。前端由業(yè)務(wù)流程和設(shè)計(jì)來驅(qū)動(dòng)，希望按順序產(chǎn)出;后端則由業(yè)務(wù)資源和建模來驅(qū)動(dòng)，希望按模塊來產(chǎn)出。

比如說，前端常常會(huì)因?yàn)樵O(shè)計(jì)的原因調(diào)整自己需要的字段，而后端從建模的角度并沒有這個(gè)需要，也沒有動(dòng)力頻繁地去跟隨前端的調(diào)整，使得前端不得不在不穩(wěn)定的網(wǎng)絡(luò)條件下傳輸多余的信息，占用了寶貴的網(wǎng)絡(luò)帶寬。

此外，前端呈現(xiàn)某個(gè)業(yè)務(wù)步驟的時(shí)候，有兩種信息不屬于當(dāng)前必備信息，但常常需要和必要信息一起展示。一種是狀態(tài)信息，比如當(dāng)前的登錄狀態(tài)和用戶名，短消息的數(shù)量等等。一種是垂直相關(guān)的信息，比如在展示文章的時(shí)候順便展示一下相關(guān)的文章。

這就要求前端在調(diào)用主服務(wù)的同時(shí)還要再調(diào)用多個(gè)不同的服務(wù)。且不說這些服務(wù)有可能會(huì)有調(diào)用超時(shí)、出錯(cuò)的可能，僅僅是多出來一堆異步請(qǐng)求，就已經(jīng)足夠讓前端效率降低一大截了。

在微服務(wù)體系下，這些問題更加嚴(yán)重，因?yàn)楝F(xiàn)在不僅僅是前后端的差別，不同服務(wù)還由不同團(tuán)隊(duì)負(fù)責(zé)。這些團(tuán)隊(duì)的訴求和日程不一，很難做到前端所需要的快速響應(yīng)。

這些問題和麻煩可能會(huì)催生一個(gè)“緩沖帶”，比如后端出專人來負(fù)責(zé)對(duì)接前端的需要，或者前端派駐一個(gè)人到后端來談需求。按康威定律，這種溝通體系，久而久之，很容易以軟件的形式沉淀下來，形成一個(gè)專屬的中間層。

要調(diào)和前后端的不同步是不可能的，而這種中間層是自然催生的解決方案，可以保留。新的問題是，它的職責(zé)是什么?應(yīng)該把它放在哪?應(yīng)該由誰來維護(hù)?

分析下來，其責(zé)任有二。***是解耦前后端的工作，降低相互的影響。前端需要的東西可以寫在中間層里，讓它頻繁變化也沒有關(guān)系。后端如果還沒有準(zhǔn)備好，前端也可以在這一層模擬假的數(shù)據(jù)，不至于被阻塞。第二則是提升前端的運(yùn)行效率。前端可以把所需要的多個(gè)服務(wù)的東西統(tǒng)一匯總，一次拿完，免得發(fā)多個(gè)請(qǐng)求。

放置的位置則在 API 網(wǎng)關(guān)之內(nèi)，讓它可以享有 API 網(wǎng)關(guān)所帶來的好處和保護(hù)。

***是維護(hù)問題。按照“誰主張，誰舉證”的原則，既然有了這個(gè)中間層，好處讓前端得了，那么，理論上應(yīng)該由前端來維護(hù)。

這樣，一個(gè)主要為前端服務(wù)的中間層就定義好了。不同類型的前端(桌面、移動(dòng))可能會(huì)有不同的需要，為了避免中間層的碎片化，我們可以讓各個(gè)中間層都特定的前端類型緊密耦合，比如桌面專用、移動(dòng)專用。如此，每個(gè)中間層都像是某類型前端的專享后端，所以“前置后端”(Backend-for-Frontend，簡(jiǎn)稱 BFF)也因此得名。

回路熔斷器：提高容錯(cuò)度

現(xiàn)在，調(diào)試也方便了，我們又繼續(xù)開發(fā)。一開始沒有什么問題，但部署到預(yù)生產(chǎn)環(huán)境的時(shí)候，又一個(gè)問題出現(xiàn)了：整個(gè)體系的容錯(cuò)度很低。一個(gè)小錯(cuò)誤容易被層層傳遞和放大，導(dǎo)致整個(gè)體系的崩潰。

我們都知道，編程最麻煩的就是遠(yuǎn)程調(diào)用。本地調(diào)用大部分時(shí)候結(jié)果是“成功”或“失敗”，但遠(yuǎn)程調(diào)用則很可能是“無響應(yīng)”。“無響應(yīng)”有可能是正常的，對(duì)方可能稍后會(huì)給你結(jié)果，也可能是因?yàn)閷?duì)方已經(jīng)死了，沒法給你響應(yīng)。最壞的結(jié)果，就是門口擠滿了人，大家都在等你給結(jié)果，而你也在等別人給結(jié)果，資源全部占用來等，什么也做不了。

不過，遠(yuǎn)程調(diào)用是無法避免的。在微服務(wù)體系中，這個(gè)問題被進(jìn)一步放大。這是因?yàn)槲⒎?wù)的模塊化以服務(wù)為單位，而每個(gè)服務(wù)獨(dú)立部署和運(yùn)維，使得服務(wù)之間的調(diào)用成了家常便飯。

在這種嚴(yán)峻的情況下，我們必須從架構(gòu)上盡量提高整個(gè)服務(wù)體系的容錯(cuò)度，讓個(gè)別服務(wù)的問題不至于影響到全局。

具體的做法，則是給遠(yuǎn)程調(diào)用加一個(gè)熔斷閾值檢查，當(dāng)調(diào)用超時(shí)次數(shù)超過閾值時(shí)，就不再調(diào)用，直接返回錯(cuò)誤。過一段時(shí)間之后，再把閾值恢復(fù)，嘗試?yán)^續(xù)調(diào)用，重復(fù)前面的過程。這個(gè)機(jī)制就是回路熔斷，而這個(gè)工具則是回路熔斷器(Circuit Breaker)。

除了隔離已經(jīng)出錯(cuò)的服務(wù)實(shí)例，熔斷器還有一個(gè)重要的功能是提供備用方案。雖然我們把所有業(yè)務(wù)都拆成了服務(wù)，但服務(wù)有高低貴賤之分。有一些服務(wù)屬于關(guān)鍵服務(wù)，一旦出問題，則整個(gè)流程無法繼續(xù)，有一些則屬于分支服務(wù)，即便錯(cuò)了，也不會(huì)影響大局。

比如說，購買商品的時(shí)候，常常會(huì)根據(jù)用戶的習(xí)慣和當(dāng)前正在購買的東西做一些推薦。負(fù)責(zé)推薦的服務(wù)出問題的話，大不了就不推薦了，不應(yīng)該影響用戶正常的購買流程。同理，如果是在線點(diǎn)餐的地址定位服務(wù)出問題了，我們也應(yīng)該允許用戶手動(dòng)選擇餐廳進(jìn)行點(diǎn)餐——體驗(yàn)雖然不佳，但至少正常的流程仍然可以走完?；谶@個(gè)考慮，熔斷器應(yīng)該為非必要的服務(wù)調(diào)用提供備用方案，盡量保證核心流程的順暢。

[[210871]]

有了回路熔斷器，遠(yuǎn)程調(diào)用出錯(cuò)的問題就從一定程度上緩解了。結(jié)合回路熔斷器和對(duì)熔斷閾值變化的監(jiān)控，開發(fā)者可以更容易地發(fā)現(xiàn)問題，并及時(shí)采取行動(dòng)。

負(fù)載均衡器：提升服務(wù)彈性

要正式上線，我們還必須做好負(fù)載均衡(Load Balancing，下簡(jiǎn)稱 LB)，提升整個(gè)服務(wù)的彈性。要做負(fù)載均衡，從理論上有兩種方式：

• 客戶端負(fù)載均衡(Client-Side LB)：由客戶端來決定如何分散請(qǐng)求。
• 中間方負(fù)載均衡(Mid-Tier LB)：由 DNS、網(wǎng)關(guān)等中間方來決定如何分散請(qǐng)求。

現(xiàn)在，服務(wù)名冊(cè)中已經(jīng)有了服務(wù)及其對(duì)應(yīng)的實(shí)例地址列表，所以客戶端的負(fù)載均衡最簡(jiǎn)便的方式就是把地址拉下來，然后依次或者隨機(jī)選擇可用的地址。中間方的負(fù)載均衡則選擇面較多，從最外層的 DNS 到網(wǎng)關(guān)都可以不同程度地去按需要去做。

擴(kuò)展基建

現(xiàn)在，微服務(wù)基建基本完成了。如果有需要，我們可以對(duì)這個(gè)基建進(jìn)行擴(kuò)展。在做擴(kuò)展時(shí)，架構(gòu)師應(yīng)該注意區(qū)分哪些東西應(yīng)該中心化，哪些東西應(yīng)該由服務(wù)自行決定。 比如說，在本文提到的基建之中，(幾乎是)強(qiáng)制完全中心化的模塊有：

• 配置管理
• 服務(wù)名冊(cè)
• 消息隊(duì)列

其中，配置管理和服務(wù)名冊(cè)是所有服務(wù)都需要的基礎(chǔ)設(shè)施，必然需要統(tǒng)一。消息隊(duì)列和日志收集都是為了跨服務(wù)的操作和追蹤，也必須中心化。

半中心化的模塊則有：

• 路由
• 鑒權(quán)

路由和鑒權(quán)都必須統(tǒng)一，我們前面討論過。不過，微服務(wù)可能會(huì)向外界暴露“自用”和“客用”等多套公共 API(比如快遞公司內(nèi)部使用的物流 API 和開放給第三方使用的物流 API)，所以可能會(huì)有兩個(gè) API 網(wǎng)關(guān)，對(duì)應(yīng)會(huì)有兩套 API 目錄和兩套鑒權(quán)體系，所以，它們是“半中心化”。

這些都是中心化、半中心化的選擇范例。每一次中心化的選擇都可能會(huì)讓整個(gè)架構(gòu)變得死板，失去靈活性，所以，我們?cè)谠O(shè)計(jì)和擴(kuò)展基建的時(shí)候應(yīng)該特別注意這個(gè)問題。

除了中心化的選擇之外，架構(gòu)發(fā)展的另一個(gè)關(guān)注點(diǎn)，是讓業(yè)務(wù)保持“黑盒”。

我們把每個(gè)服務(wù)之間的關(guān)聯(lián)抽取了出來，也把權(quán)限的定義和驗(yàn)證抽取了出來，每個(gè)服務(wù)變得簡(jiǎn)單而純粹，成了“純業(yè)務(wù)式服務(wù)”，等同于一個(gè)僅包含了業(yè)務(wù)規(guī)則的黑盒。這樣，不管服務(wù)和模塊再多，也沒有影響。業(yè)務(wù)的重用性也很高。

總而言之，搭建好了微服務(wù)的必要設(shè)施之后，剩下的就要根據(jù)實(shí)際情況和項(xiàng)目經(jīng)驗(yàn)來繼續(xù)調(diào)整了。比如，我們可能會(huì)選擇把很多功能合并到一層，以避免過度分層所帶來的不必要的性能損失，或者對(duì)整個(gè)基建進(jìn)行一些細(xì)節(jié)微調(diào)。只要把控好“中心-自理”和“業(yè)務(wù)-非業(yè)務(wù)”之間的關(guān)系，這個(gè)基礎(chǔ)設(shè)施就能健康地發(fā)展。

微服務(wù)基建總結(jié)

總結(jié)此文，微服務(wù)的基建應(yīng)該包括如下一些組件(按請(qǐng)求流中的出場(chǎng)順序)：

• 配置管理：配置集中管理。
• API 網(wǎng)關(guān)：對(duì)外的 API 總目錄;API 依賴關(guān)系;發(fā)起鑒權(quán)。
• 服務(wù)名冊(cè)：服務(wù)的注冊(cè)和發(fā)現(xiàn)。
• 鑒權(quán)服務(wù)：提供鑒權(quán)服務(wù)：認(rèn)證身份，驗(yàn)證功能權(quán)限。
• 前置后端：按前端的需求拆解請(qǐng)求、調(diào)用服務(wù)，并匯總、轉(zhuǎn)換結(jié)果。
• 消息中介：全局通知機(jī)制;異步調(diào)用機(jī)制。
• 回路熔斷：隔離出問題的服務(wù)并等待其恢復(fù);提供備用方案。
• 負(fù)載均衡：避免服務(wù)過載。

需要說明的是，這些組件的組合形式，具體拆分形式，是否需要，都需要結(jié)合實(shí)際項(xiàng)目和團(tuán)隊(duì)的情況來調(diào)整。本文權(quán)作拋磚引玉，請(qǐng)讀者知悉。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文