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

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

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

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

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

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

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

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

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

分解模式

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

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

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

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

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

子域可以分為如下幾類：

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

一個訂單管理的子域包括：

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

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

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

• 準(zhǔn)備階段 —— 在這個階段，事務(wù)的所有參與者都準(zhǔn)備提交并通知協(xié)調(diào)員他們已準(zhǔn)備好完成事務(wù)

• 提交或回滾階段 —— 在這個階段，事務(wù)協(xié)調(diào)器向所有參與者發(fā)出提交或回滾命令

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

絞殺者模式（Strangler Pattern）

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

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

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

隔艙模式（Bulkhead Pattern）

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

邊車模式

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

集成模式

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

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

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

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

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

聚合器模式（Aggregator Pattern）

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

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

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

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

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

代理模式

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

1、移動端 API，它實(shí)現(xiàn)了 FTGO 移動客戶端的 API 2、瀏覽器端 API，它實(shí)現(xiàn)了在瀏覽器里運(yùn)行的 JavaScript 應(yīng)用程序的 API 3、公共API，它實(shí)現(xiàn)了一些第三方開發(fā)人員需要的 API

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

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

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

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

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

分支模式

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

客戶端UI組合模式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

事件驅(qū)動

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

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

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

Saga模式

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

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

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

可觀測性模式

日志聚合

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

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

性能指標(biāo)

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

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

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

分布式鏈路追蹤

在微服務(wù)架構(gòu)里，請求通常跨越多個服務(wù)。每個服務(wù)通過跨越多個服務(wù)執(zhí)行一個或多個操作來處理請求。在排障時，有一個 Trace ID 是很有幫助的，我們可以端對端地跟蹤一個請求。

解決方案便是引入一個事務(wù)ID。可以采用如下方式：

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

健康檢查

實(shí)施微服務(wù)架構(gòu)后，服務(wù)可能會出現(xiàn)啟動了但是無法處理事務(wù)的情況。每個服務(wù)都需要有一個可用于檢查應(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）

外部配置

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

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

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

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

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

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

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

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

熔斷器模式

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

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

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

藍(lán)綠部署模式

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

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

鏈接：colstuwjx.github.io/2020/01/%E7%BF%BB%E8%AF%91-%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E5%8F%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F/

（版權(quán)歸原作者所有，侵刪）