本文介紹了主流常見(jiàn)的微服務(wù)模式。

微服務(wù)能夠?qū)ζ髽I(yè)產(chǎn)生積極影響。因此，了解如何處理微服務(wù)架構(gòu)（MSA）以及一些微服務(wù)設(shè)計(jì)模式，一個(gè)微服務(wù)架構(gòu)的一些通用目標(biāo)或者設(shè)計(jì)原則是很有價(jià)值的。下面是在微服務(wù)架構(gòu)方案中值得考慮的四個(gè)目標(biāo)。

1、縮減成本：MSA將會(huì)降低設(shè)計(jì)、實(shí)現(xiàn)和維護(hù)IT服務(wù)的總體成本

2、加快發(fā)布速度：MSA將會(huì)加快服務(wù)從想法到部署的落地速度

3、增強(qiáng)彈性：MSA將會(huì)提升我們服務(wù)網(wǎng)絡(luò)的彈性

4、開(kāi)啟可見(jiàn)性：MSA支持為服務(wù)和網(wǎng)絡(luò)提供更好的可見(jiàn)性

你需要了解建設(shè)微服務(wù)架構(gòu)背后的幾個(gè)設(shè)計(jì)原則：

• 可擴(kuò)展性
• 可用性
• 韌性
• 靈活性
• 獨(dú)立自主性，自治性
• 去中心化治理
• 故障隔離
• 自動(dòng)裝配
• 通過(guò) DevOps 持續(xù)交付

聽(tīng)取上述原則，在你實(shí)施的解決方案或系統(tǒng)付諸實(shí)踐的同時(shí)，這也會(huì)帶來(lái)一些挑戰(zhàn)和問(wèn)題。這些問(wèn)題在許多解決方案中也很常見(jiàn)。使用正確及匹配的設(shè)計(jì)模式可以克服這些問(wèn)題。微服務(wù)有一些設(shè)計(jì)模式，這可以大體分為五類。每類都包含許多具體的設(shè)計(jì)模式。下圖展示了這些設(shè)計(jì)模式。

分解模式

按業(yè)務(wù)功能進(jìn)行分解

說(shuō)白了，微服務(wù)就是要應(yīng)用單一職責(zé)原則，把服務(wù)改造成松耦合式的。它可以按照業(yè)務(wù)功能進(jìn)行分解。定義和業(yè)務(wù)功能相對(duì)應(yīng)的服務(wù)。業(yè)務(wù)功能是一個(gè)來(lái)自業(yè)務(wù)架構(gòu)建模的概念。它是一個(gè)企業(yè)為了創(chuàng)造價(jià)值而要去做的某些事情。一個(gè)業(yè)務(wù)功能往往對(duì)應(yīng)于一個(gè)業(yè)務(wù)對(duì)象，比如：

• 訂單管理負(fù)責(zé)訂單
• 客戶管理則是負(fù)責(zé)客戶

按問(wèn)題子域進(jìn)行分解

按照業(yè)務(wù)功能來(lái)分解一個(gè)應(yīng)用程序可能會(huì)是一個(gè)不錯(cuò)的開(kāi)始，但是你終將會(huì)遇到所謂的“神類”，它很難再被分解。這些類將在多個(gè)服務(wù)之間都是通用的?？梢远x一些和領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）里面的子域相對(duì)應(yīng)的服務(wù)。DDD 把應(yīng)用程序的問(wèn)題空間 —— 也即是業(yè)務(wù) —— 稱之為域。一個(gè)域由多個(gè)子域組成。每個(gè)子域?qū)?yīng)業(yè)務(wù)的各個(gè)不同部分。

子域可以分為如下幾類：

• 核心 —— 業(yè)務(wù)的核心競(jìng)爭(zhēng)力以及應(yīng)用程序最有價(jià)值的部分
• 支撐 —— 和業(yè)務(wù)有關(guān)但并不是一個(gè)核心競(jìng)爭(zhēng)力。這些可以在內(nèi)部實(shí)現(xiàn)也可以外包
• 通用 —— 不特定于業(yè)務(wù)，而且在理想情況下可以使用現(xiàn)成的軟件實(shí)現(xiàn)

一個(gè)訂單管理的子域包括：

• 產(chǎn)品目錄服務(wù)
• 庫(kù)存管理服務(wù)
• 訂單管理服務(wù)
• 配送管理服務(wù)

按事務(wù)/兩階段提交（2pc）模式進(jìn)行分解

你可以通過(guò)事務(wù)分解服務(wù)。然后，這樣一來(lái)系統(tǒng)里將會(huì)存在多個(gè)事務(wù)。事務(wù)處理協(xié)調(diào)器是分布式事務(wù)處理的重要參與者之一。分布式事務(wù)包括兩個(gè)步驟：

• 準(zhǔn)備階段 —— 在這個(gè)階段，事務(wù)的所有參與者都準(zhǔn)備提交并通知協(xié)調(diào)員他們已準(zhǔn)備好完成事務(wù)
• 提交或回滾階段 —— 在這個(gè)階段，事務(wù)協(xié)調(diào)器向所有參與者發(fā)出提交或回滾命令

2PC 的問(wèn)題在于，和單個(gè)微服務(wù)的運(yùn)行時(shí)間相比，它顯得相當(dāng)慢。即便這些微服務(wù)跑在相同的網(wǎng)絡(luò)里，它們之間的事務(wù)協(xié)調(diào)也確實(shí)會(huì)減慢系統(tǒng)速度，因此這種方法通常不適用于高負(fù)載情況。

絞殺者模式（Strangler Pattern）

上面三種，我們看到的這幾個(gè)設(shè)計(jì)模式都是用來(lái)分解綠場(chǎng)（Greenfield）的應(yīng)用程序，但是往往我們所做的工作中有 80％ 是針對(duì)灰場(chǎng)（brownfield）應(yīng)用程序，它們是一些大型的單體應(yīng)用程序（歷史遺留的代碼庫(kù)）。

絞殺者模式可以解決這類問(wèn)題。它會(huì)創(chuàng)建兩個(gè)單獨(dú)的應(yīng)用程序，它們并排跑在同一個(gè) URI 空間里。隨著時(shí)間的流逝，直到最后，新重構(gòu)的應(yīng)用程序會(huì)“干掉”或替換原有的應(yīng)用程序，此時(shí)就可以關(guān)掉那個(gè)老的單體應(yīng)用程序。絞殺應(yīng)用程序的步驟分別是轉(zhuǎn)換，共存和消除：

• 轉(zhuǎn)換（Transform） —— 使用現(xiàn)代方法創(chuàng)建一個(gè)并行的全新站點(diǎn)。
• 共存（Coexist） —— 讓現(xiàn)有站點(diǎn)保留一段時(shí)間。把針對(duì)現(xiàn)有站點(diǎn)的訪問(wèn)重定向到新站點(diǎn)，以便逐步實(shí)現(xiàn)所需功能。
• 消除（Eliminate） —— 從現(xiàn)有站點(diǎn)中刪除舊功能。

隔艙模式（Bulkhead Pattern）

讓一個(gè)應(yīng)用程序的元素和池子相對(duì)隔離，這樣一來(lái)，其他應(yīng)用程序?qū)⒖梢岳^續(xù)正常工作。這種模式被稱為“隔艙”，因?yàn)樗愃朴诖w的分段分區(qū)。根據(jù)使用者負(fù)載和可用性要求，將服務(wù)實(shí)例分成不同的組。這種設(shè)計(jì)有助于隔離故障，并允許用戶即使在故障期間仍可為某些使用者維持服務(wù)。

邊車模式

該模式將一個(gè)應(yīng)用程序的組件部署到一個(gè)單獨(dú)的處理器容器里以提供隔離和封裝。它還允許應(yīng)用程序由異構(gòu)的組件和技術(shù)組成。這種模式被稱為邊車模式（Sidecar），因?yàn)樗愃朴谶B接到摩托車的側(cè)邊車。在該模式中，側(cè)邊車會(huì)附加到父應(yīng)用程序，并為該應(yīng)用程序提供功能支持。Sidecar 還與父應(yīng)用程序共享相同的生命周期，并與父應(yīng)用程序一起創(chuàng)建和退出。Sidecar 模式有時(shí)也稱為 sidekick 模式，這是我們?cè)谖恼轮辛谐龅淖詈笠粋€(gè)分解模式。

集成模式

API 網(wǎng)關(guān)模式

當(dāng)一個(gè)應(yīng)用程序被分解成多個(gè)較小的微服務(wù)時(shí)，這里會(huì)出現(xiàn)一些需要解決的問(wèn)題：

• 存在不同渠道對(duì)多個(gè)微服務(wù)的多次調(diào)用
• 需要處理不同類型的協(xié)議
• 不同的消費(fèi)者可能需要不同的響應(yīng)格式

API 網(wǎng)關(guān)有助于解決微服務(wù)實(shí)現(xiàn)引發(fā)的諸多問(wèn)題，而不僅限于上述提到的這些。

• API 網(wǎng)關(guān)是任何微服務(wù)調(diào)用的單一入口點(diǎn)
• 它可以用作將請(qǐng)求路由到相關(guān)微服務(wù)的代理服務(wù)
• 它可以匯總結(jié)果并發(fā)送回消費(fèi)者
• 該解決方案可以為每種特定類型的客戶端創(chuàng)建一個(gè)細(xì)粒度的 API
• 它還可以轉(zhuǎn)換協(xié)議請(qǐng)求并做出響應(yīng)
• 它也可以承擔(dān)微服務(wù)的身份驗(yàn)證/授權(quán)的責(zé)任。

聚合器模式（Aggregator Pattern）

將業(yè)務(wù)功能分解成幾個(gè)較小的邏輯代碼段后就有必要考慮如何協(xié)同每個(gè)服務(wù)返回的數(shù)據(jù)。不能把這個(gè)職責(zé)留給消費(fèi)者。

聚合器模式有助于解決這個(gè)問(wèn)題。它討論了如何聚合來(lái)自不同服務(wù)的數(shù)據(jù)，然后將最終響應(yīng)發(fā)送給消費(fèi)者。這里有兩種實(shí)現(xiàn)方式：

1、一個(gè)組合微服務(wù)將調(diào)用所有必需的微服務(wù)，合并數(shù)據(jù)，然后在發(fā)送回?cái)?shù)據(jù)之前對(duì)其進(jìn)行轉(zhuǎn)換合成

2、一個(gè) API 網(wǎng)關(guān)還可以將請(qǐng)求劃分成多個(gè)微服務(wù)，然后在將數(shù)據(jù)發(fā)送給使用者之前匯總數(shù)據(jù)

如果要應(yīng)用一些業(yè)務(wù)邏輯的話，建議選擇一個(gè)組合式的微服務(wù)。除此之外，API 網(wǎng)關(guān)作為這個(gè)問(wèn)題的解決方案已經(jīng)是既定的事實(shí)標(biāo)準(zhǔn)。

代理模式

針對(duì) API 網(wǎng)關(guān)，我們只是借助它來(lái)對(duì)外公開(kāi)我們的微服務(wù)。引入 API 網(wǎng)關(guān)后，我們得以獲得一些像安全性和對(duì) API 進(jìn)行分類這樣的 API 層面功能。在這個(gè)例子里，API 網(wǎng)關(guān)有三個(gè) API 模塊：

1、移動(dòng)端 API，它實(shí)現(xiàn)了 FTGO 移動(dòng)客戶端的 API

2、瀏覽器端 API，它實(shí)現(xiàn)了在瀏覽器里運(yùn)行的 JavaScript 應(yīng)用程序的 API

3、公共API，它實(shí)現(xiàn)了一些第三方開(kāi)發(fā)人員需要的 API

網(wǎng)關(guān)路由模式

API 網(wǎng)關(guān)負(fù)責(zé)路由請(qǐng)求。一個(gè) API 網(wǎng)關(guān)通過(guò)將請(qǐng)求路由到相應(yīng)的服務(wù)來(lái)實(shí)現(xiàn)一些 API 操作。當(dāng) API 網(wǎng)關(guān)接收到請(qǐng)求時(shí)，它會(huì)查詢一個(gè)路由映射，該路由映射指定了將請(qǐng)求路由到哪個(gè)服務(wù)。一個(gè)路由映射可以將一個(gè) HTTP 方法和路徑映射到服務(wù)的 HTTP URL。這種做法和像 NGINX 這樣的 Web 服務(wù)器提供的反向代理功能一樣。

鏈?zhǔn)轿⒎?wù)模式（Chained Microservice Pattern）

單個(gè)服務(wù)或者微服務(wù)將會(huì)有多級(jí)依賴，舉個(gè)例子：Sale 的微服務(wù)依賴 Product 微服務(wù)和 Order 微服務(wù)。鏈?zhǔn)轿⒎?wù)設(shè)計(jì)模式將幫助你提供合并后的請(qǐng)求結(jié)果。

microservice-1 接收到請(qǐng)求后，該請(qǐng)求隨后與 microservice-2 進(jìn)行通信，還有可能正在和 microservice-3 通信。所有這些服務(wù)都是同步調(diào)用。

分支模式

一個(gè)微服務(wù)可能需要從包括其他微服務(wù)在內(nèi)的多個(gè)來(lái)源獲取數(shù)據(jù)。分支微服務(wù)模式是聚合器和鏈?zhǔn)皆O(shè)計(jì)模式的混合，并允許來(lái)自兩個(gè)或多個(gè)微服務(wù)的同時(shí)請(qǐng)求/響應(yīng)處理。調(diào)用的微服務(wù)可以是一個(gè)微服務(wù)鏈。分支模式還可用于根據(jù)你的業(yè)務(wù)需求調(diào)用不同的微服務(wù)鏈或單個(gè)鏈。

客戶端UI組合模式

通過(guò)分解業(yè)務(wù)功能/子域來(lái)開(kāi)發(fā)服務(wù)時(shí)，負(fù)責(zé)用戶體驗(yàn)的服務(wù)必須從多個(gè)微服務(wù)中提取數(shù)據(jù)。在一個(gè)單體世界里，過(guò)去只有一個(gè)從 UI 到后端服務(wù)的調(diào)用，它會(huì)檢索所有數(shù)據(jù)然后刷新/提交 UI 頁(yè)面。但是，現(xiàn)在不一樣了。

對(duì)于微服務(wù)而言，我們必須把 UI 設(shè)計(jì)成一個(gè)具有屏幕/頁(yè)面的多個(gè)板塊/區(qū)域的框架。每個(gè)板塊都將調(diào)用一個(gè)單獨(dú)的后端微服務(wù)以提取數(shù)據(jù)。

諸如 AngularJS 和 ReactJS 之類的框架可以幫助我們輕松地實(shí)現(xiàn)這一點(diǎn)。這些屏幕稱為單頁(yè)應(yīng)用程序（SPA）。

每個(gè)團(tuán)隊(duì)都開(kāi)發(fā)一個(gè)客戶端 UI 組件，比如一個(gè) AngularJS 指令，該組件實(shí)現(xiàn)其服務(wù)的頁(yè)面/屏幕區(qū)域。UI 團(tuán)隊(duì)負(fù)責(zé)通過(guò)組合多個(gè)特定服務(wù)的 UI 組件來(lái)實(shí)現(xiàn)構(gòu)建頁(yè)面/屏幕的頁(yè)面框架。

數(shù)據(jù)庫(kù)模式

給微服務(wù)定義數(shù)據(jù)庫(kù)架構(gòu)時(shí)，我們需要考慮以下幾點(diǎn)：

1、服務(wù)必須是松耦合的。這樣它們可以獨(dú)立開(kāi)發(fā)，部署和擴(kuò)展

2、業(yè)務(wù)事務(wù)可能會(huì)強(qiáng)制跨越多個(gè)服務(wù)的不變量

3、一些業(yè)務(wù)事務(wù)需要查詢多個(gè)服務(wù)的數(shù)據(jù)

4、為了可擴(kuò)展性考慮，數(shù)據(jù)庫(kù)有時(shí)候必須是可復(fù)制和共享的

5、不同服務(wù)存在不同的數(shù)據(jù)存儲(chǔ)要求

每個(gè)服務(wù)一套數(shù)據(jù)庫(kù)

為了解決上述問(wèn)題，必須為每個(gè)微服務(wù)設(shè)計(jì)一個(gè)數(shù)據(jù)庫(kù)。它必須僅專用于該服務(wù)。應(yīng)當(dāng)只能通過(guò)微服務(wù)的 API 訪問(wèn)它。其他服務(wù)無(wú)法直接訪問(wèn)它。比如，針對(duì)關(guān)系型數(shù)據(jù)庫(kù)，我們可以采用每個(gè)服務(wù)使用單獨(dú)的專用表（private-tables-per-service），每個(gè)服務(wù)單獨(dú)的數(shù)據(jù)庫(kù)模式（schema-per-service）或每個(gè)服務(wù)單獨(dú)的數(shù)據(jù)庫(kù)服務(wù)器（database-server-per-service）。

服務(wù)之間共享數(shù)據(jù)庫(kù)

我們已經(jīng)說(shuō)過(guò)，在微服務(wù)里，為每個(gè)服務(wù)分配一套單獨(dú)的數(shù)據(jù)庫(kù)是理想方案。采用共享數(shù)據(jù)庫(kù)在微服務(wù)里屬于反模式。但是，如果應(yīng)用程序是一個(gè)單體應(yīng)用而且試圖拆分成微服務(wù)，那么反正規(guī)化就不那么容易了。

在后面的階段里，我們可以轉(zhuǎn)到每個(gè)服務(wù)一套數(shù)據(jù)庫(kù)的模式，直到我們完全做到了這一點(diǎn)。服務(wù)之間共享數(shù)據(jù)庫(kù)并不理想，但是對(duì)于上述情況，它是一個(gè)切實(shí)可行的解決方案。大多數(shù)人認(rèn)為這是微服務(wù)的反模式，但是對(duì)于灰場(chǎng)應(yīng)用程序，這是將應(yīng)用程序分解成更小邏輯部分的一個(gè)很好的開(kāi)始。值得一提的是，這不應(yīng)當(dāng)應(yīng)用于綠場(chǎng)應(yīng)用程序。

命令和查詢職責(zé)分離 (CQRS)

一旦實(shí)現(xiàn)了每個(gè)服務(wù)分配單獨(dú)一套數(shù)據(jù)庫(kù)（database-per-service），自然就會(huì)產(chǎn)生查詢需求，這需要聯(lián)合來(lái)自多個(gè)服務(wù)的數(shù)據(jù)。然而這是不可能的。CQRS 建議將應(yīng)用程序分成兩部分 —— 命令端和查詢端。

• 命令端處理創(chuàng)建，更新和刪除請(qǐng)求
• 查詢端通過(guò)使用物化視圖來(lái)處理查詢部分

這通常會(huì)搭配事件驅(qū)動(dòng)模式（event sourcing pattern）一起使用，一旦有任何數(shù)據(jù)更改便會(huì)創(chuàng)建對(duì)應(yīng)的事件。通過(guò)訂閱事件流，我們便可以讓物化視圖保持更新。

事件驅(qū)動(dòng)

絕大多數(shù)應(yīng)用程序需要用到數(shù)據(jù)，典型的做法就是應(yīng)用程序要維護(hù)當(dāng)前狀態(tài)。例如，在傳統(tǒng)的創(chuàng)建，讀取，更新和刪除（CRUD）模型中，典型的數(shù)據(jù)流程是從存儲(chǔ)中讀取數(shù)據(jù)。它也包含了經(jīng)常使用事務(wù)導(dǎo)致鎖定數(shù)據(jù)的限制。

事件驅(qū)動(dòng)模式定義了一種方法，用于處理由一系列事件驅(qū)動(dòng)的數(shù)據(jù)操作，每個(gè)事件都記錄在一個(gè) append-only 的存儲(chǔ)中。應(yīng)用程序代碼向事件存儲(chǔ)發(fā)送一系列事件，這些事件命令式的描述了對(duì)數(shù)據(jù)執(zhí)行的每個(gè)操作，它們會(huì)被持久化到事件存儲(chǔ)。每個(gè)事件代表一組數(shù)據(jù)更改（例如，AddedItemToOrder）。

這些事件將保留在充當(dāng)記錄系統(tǒng)的一個(gè)事件存儲(chǔ)里。事件存儲(chǔ)發(fā)布的事件的典型用途是在應(yīng)用程序觸發(fā)的一些動(dòng)作更改實(shí)體時(shí)維護(hù)這些實(shí)體的物化視圖，以及與外部系統(tǒng)集成。例如，一個(gè)系統(tǒng)可以維護(hù)一個(gè)用于填充 UI 部分所有客戶訂單的物化視圖。當(dāng)應(yīng)用程序添加新訂單，添加或刪除訂單中的項(xiàng)目以及添加運(yùn)輸信息時(shí)，描述這些更改的事件將會(huì)得到處理并用于更新物化視圖。下圖展示了該模式的一個(gè)概覽。

Saga模式

當(dāng)每個(gè)服務(wù)都有它們自己的數(shù)據(jù)庫(kù)，并且一個(gè)業(yè)務(wù)事務(wù)跨越多個(gè)服務(wù)時(shí)，我們?cè)撊绾未_保各個(gè)服務(wù)之間的數(shù)據(jù)一致性呢？每個(gè)請(qǐng)求都有一個(gè)補(bǔ)償請(qǐng)求，它會(huì)在請(qǐng)求失敗時(shí)執(zhí)行。這可以通過(guò)兩種方式實(shí)現(xiàn)：

• 編舞（Choreography） —— 在沒(méi)有中央?yún)f(xié)調(diào)的情況下，每個(gè)服務(wù)都會(huì)生成并偵聽(tīng)另一個(gè)服務(wù)的事件，并決定是否應(yīng)該采取措施。編舞是一種指定兩個(gè)或多個(gè)參與方的方案。任何一方都無(wú)法控制對(duì)方的流程，或者對(duì)這些流程有任何可見(jiàn)性，無(wú)法協(xié)調(diào)他們的活動(dòng)和流程以共享信息和值。當(dāng)需要跨控制/可見(jiàn)性域進(jìn)行協(xié)調(diào)時(shí)，請(qǐng)使用編舞的方式。參考一個(gè)簡(jiǎn)單場(chǎng)景，你可以把編舞看作和網(wǎng)絡(luò)協(xié)議類似。它規(guī)定了各方之間可接受的請(qǐng)求和響應(yīng)模式。

sage pattern

• 編排（Orchestration） —— 一個(gè)編排器（對(duì)象）會(huì)負(fù)責(zé) saga 的決策和業(yè)務(wù)邏輯排序。此時(shí)你可以控制流程中的所有參與者。當(dāng)它們?nèi)刻幱谝粋€(gè)控制域時(shí)，你可以控制該活動(dòng)的流程。當(dāng)然，這通常是你被指派到一個(gè)擁有控制權(quán)的組織里制定業(yè)務(wù)流程。

saga-pattern-orchestration

可觀測(cè)性模式

日志聚合

考慮一個(gè)應(yīng)用程序包含多個(gè)服務(wù)的用例。請(qǐng)求通?？缭蕉鄠€(gè)服務(wù)實(shí)例。每個(gè)服務(wù)實(shí)例均采用標(biāo)準(zhǔn)格式生成日志文件。我們需要一個(gè)集中式的日志記錄服務(wù)，該服務(wù)可以匯總每個(gè)服務(wù)實(shí)例的日志。

用戶可以搜索和分析日志。他們可以配置在某些消息出現(xiàn)在日志中時(shí)觸發(fā)告警。例如，PCF 就有日志聚合器，它在應(yīng)用側(cè)從 PCF 平臺(tái)的每個(gè)組件（router、controller、diego等）收集日志。AWS Cloud Watch 也是這樣做的。

性能指標(biāo)

當(dāng)服務(wù)組合由于引入了微服務(wù)架構(gòu)而增加時(shí)，保持對(duì)事務(wù)的監(jiān)控就變得尤為關(guān)鍵了，如此一來(lái)就可以監(jiān)控這些模式，而當(dāng)有問(wèn)題發(fā)生時(shí)便會(huì)發(fā)送告警。

此外，需要一個(gè)度量服務(wù)來(lái)收集有關(guān)單個(gè)操作的統(tǒng)計(jì)信息。它應(yīng)當(dāng)聚合一個(gè)應(yīng)用服務(wù)的指標(biāo)數(shù)據(jù)，它會(huì)用來(lái)報(bào)告和告警。這里有兩種用于匯總指標(biāo)的模型：

• 推送 —— 服務(wù)將指標(biāo)推送到指標(biāo)服務(wù)，例如 NewRelic，AppDynamics
• 提取 —— 指標(biāo)服務(wù)從服務(wù)中提取指標(biāo)，例如 Prometheus

分布式鏈路追蹤

在微服務(wù)架構(gòu)里，請(qǐng)求通?？缭蕉鄠€(gè)服務(wù)。每個(gè)服務(wù)通過(guò)跨越多個(gè)服務(wù)執(zhí)行一個(gè)或多個(gè)操作來(lái)處理請(qǐng)求。在排障時(shí)，有一個(gè) Trace ID 是很有幫助的，我們可以端對(duì)端地跟蹤一個(gè)請(qǐng)求。

解決方案便是引入一個(gè)事務(wù)ID?？梢圆捎萌缦路绞剑?/p>

• 為每個(gè)外部請(qǐng)求分配一個(gè)唯一的外部請(qǐng)求ID
• 將外部請(qǐng)求ID傳遞給處理該請(qǐng)求鏈路的所有服務(wù)
• 在所有日志消息中加入該外部請(qǐng)求ID

健康檢查

實(shí)施微服務(wù)架構(gòu)后，服務(wù)可能會(huì)出現(xiàn)啟動(dòng)了但是無(wú)法處理事務(wù)的情況。每個(gè)服務(wù)都需要有一個(gè)可用于檢查應(yīng)用程序運(yùn)行狀況的 API 端點(diǎn)，例如 /health。該 API 應(yīng)該檢查主機(jī)的狀態(tài)，與其他服務(wù)/基礎(chǔ)設(shè)施的連接以及任何其他特定的邏輯。

橫切關(guān)注點(diǎn)模式（Cross-Cutting Concern Patterns）

外部配置

一個(gè)服務(wù)通常還會(huì)調(diào)用其他服務(wù)和數(shù)據(jù)庫(kù)。對(duì)于dev，QA，UAT，Prod等每個(gè)環(huán)境而言，API 端點(diǎn)的 URL 或某些配置屬性可能會(huì)有所不同。這些屬性中的任何一個(gè)更改都可能需要重新構(gòu)建和重新部署服務(wù)。

為避免代碼修改，可以使用配置。把所有配置放到外面，包括端點(diǎn) URL 和證書(shū)。應(yīng)用程序應(yīng)該在啟動(dòng)時(shí)或運(yùn)行時(shí)加載它們。這些可以在啟動(dòng)時(shí)由應(yīng)用程序訪問(wèn)，也可以在不重新啟動(dòng)服務(wù)器的情況下進(jìn)行刷新。

服務(wù)發(fā)現(xiàn)模式

在微服務(wù)出現(xiàn)時(shí)，我們需要在調(diào)用服務(wù)方面解決一些問(wèn)題。

借助容器技術(shù)，IP地址可以動(dòng)態(tài)地分配給服務(wù)實(shí)例。每次地址更改時(shí)，消費(fèi)端服務(wù)都會(huì)中斷并且需要手動(dòng)更改。

對(duì)于消費(fèi)端服務(wù)來(lái)說(shuō)，它們必須記住每個(gè)上游服務(wù)的 URL ，這就變成緊耦合了。

為此，需要?jiǎng)?chuàng)建一個(gè)服務(wù)注冊(cè)中心，該注冊(cè)表將保留每個(gè)生產(chǎn)者服務(wù)的元數(shù)據(jù)和每個(gè)服務(wù)的配置。服務(wù)實(shí)例在啟動(dòng)時(shí)應(yīng)當(dāng)注冊(cè)到注冊(cè)中心，而在關(guān)閉時(shí)應(yīng)當(dāng)注銷。服務(wù)發(fā)現(xiàn)有兩種類型：

• 客戶端：例如：Netflix Eureka
• 服務(wù)端：例如：AWS ALB

熔斷器模式

一個(gè)服務(wù)通常會(huì)通過(guò)調(diào)用其他服務(wù)來(lái)檢索數(shù)據(jù)，而這時(shí)候下游服務(wù)可能已經(jīng)掛了。這樣的話，有兩個(gè)問(wèn)題：首先，請(qǐng)求將繼續(xù)抵達(dá)掛了的服務(wù)，耗盡網(wǎng)絡(luò)資源，并且降低性能。其次，用戶體驗(yàn)將是糟糕且不可預(yù)測(cè)的。

消費(fèi)端服務(wù)應(yīng)通過(guò)代理來(lái)調(diào)用遠(yuǎn)程服務(wù)，該代理的表現(xiàn)和一個(gè)電流斷路器類似。當(dāng)連續(xù)的故障數(shù)超過(guò)閾值時(shí)，斷路器將跳閘，并且在超時(shí)期間內(nèi)，所有調(diào)用遠(yuǎn)程服務(wù)的嘗試都會(huì)立即失敗。超時(shí)到期后，斷路器將允許有限數(shù)量的測(cè)試請(qǐng)求通過(guò)。

如果這些請(qǐng)求成功，斷路器則將恢復(fù)正常運(yùn)行。否則，如果發(fā)生故障的話，超時(shí)時(shí)間則將再次重新開(kāi)始計(jì)算。如果某些操作失敗概率很高的話，采取此模式有助于防止應(yīng)用程序在故障發(fā)生后仍然不斷嘗試調(diào)用遠(yuǎn)程服務(wù)或訪問(wèn)共享資源。

藍(lán)綠部署模式

使用微服務(wù)架構(gòu)時(shí)，一個(gè)應(yīng)用可以被拆分成許多個(gè)微服務(wù)。如果我們采用停止所有服務(wù)然后再部署改進(jìn)版本的方式的話，宕機(jī)時(shí)間將是非?？捎^的，并且會(huì)影響業(yè)務(wù)。同樣，回滾也將是一場(chǎng)噩夢(mèng)。藍(lán)綠部署模式可以避免這種情況。

實(shí)施藍(lán)綠部署策略可以用來(lái)減少或消除宕機(jī)。它通過(guò)運(yùn)行兩個(gè)相同的生產(chǎn)環(huán)境，Blue 和Green 來(lái)實(shí)現(xiàn)這一目標(biāo)。假設(shè) Green 是現(xiàn)有的活動(dòng)實(shí)例，Blue 是該應(yīng)用程序的新版本。在任何時(shí)候，只有一個(gè)環(huán)境處于活動(dòng)狀態(tài)，該活動(dòng)環(huán)境為所有生產(chǎn)流量提供服務(wù)。所有云平臺(tái)均提供了用于實(shí)施藍(lán)綠部署的選項(xiàng)。