微服務設計模式

     微服務可以對你的企業產生積極的影響。因此，值得瞭解如何處理微服務架構（MSA）和一些微服務的設計模式，以及，微服務架構的一般目標或原則。以下是微服務架構方法中需要考慮的四個目標。

降低成本。MSA將降低設計、實施和維護IT服務的總體成本。
提高發佈速度：MSA將提高從想法到部署服務的速度。
提高複原力。MSA將提高我們服務網路的彈性。
實現可視性。MSA支持對你的服務和網路有更好的可見性。
你需要瞭解微服務架構建立的原則有哪些：

可擴展性
可用性
彈性
靈活性
獨立、自主
分散的治理
故障隔離
自動配置

通過DevOps持續交付
     遵循上述原則會帶來一些挑戰和問題，同時使你的解決方案或系統投入使用。這些問題對許多解決方案來說是很常見的。這些問題可以通過使用正確和匹配的設計模式來剋服。有一些微服務的設計模式，這些模式可以分為五個模式。每種模式都包含許多模式。

分解模式
      按業務能力分解 微服務是關於使服務鬆散耦合和應用單一責任原則。它按業務能力進行分解。定義與業務能力相對應的服務。業務能力是業務架構建模的一個概念[2]。它是一個企業為了產生價值而做的事情。一個業務能力通常對應於一個業務對象，例如

訂單管理是對訂單負責
客戶管理對客戶負責

按子域分解
       使用業務能力來分解一個應用程式可能是一個好的開始，但你會遇到所謂的 "上帝類"，這並不容易分解。這些類在多個服務中是通用的。定義對應於領域驅動設計（DDD）子域的服務。DDD將應用程式的問題空間--業務--稱為域。一個域是由多個子域組成的。每個子域對應於業務的不同部分。子域可以分類如下。

核心--企業的關鍵差異化因素和應用中最有價值的部分
支持性的--與企業的業務有關，但不是一個差異化的因素；可以在內部實施或外包
通用型--與業務無關，最好是使用現成的軟體來實施。
訂單管理的子域包括：

產品目錄服務
庫存管理服務
訂單管理服務
交付管理服務

通過事務/兩階段提交分解（2個）模式
這種模式可以將服務分解到交易中。那麼系統中就會有多個交易。分散式交易中的一個重要參與者是交易協調人[3]。分散式交易由兩個步驟組成。

準備階段--在這一階段，交易的所有參與者為提交做準備，並通知協調者他們已經準備好完成交易了
提交或回滾階段--在這個階段，交易協調人向所有參與者發出提交或回滾命令
2PC的問題是，與單個微服務的運行時間相比，它相當緩慢。協調微服務之間的交易，即使它們在同一個網路上，也會使系統變得很慢；所以這種方法通常不用於高負載的情況下。

絞殺者模式
       你所經歷的前三個設計模式是為Greenfield分解應用程式，但你所做的80%的工作是與brownfield應用程式，即大的、單一的應用程式（遺產代碼庫）。Strangler模式是一種救援或解決方案。這創造了兩個獨立的應用程式，它們在同一個URI空間中並肩生存。隨著時間的推移，新重構的應用程式會 "扼殺 "或取代原來的應用程式，直到最後，你可以關閉這個單體應用程式。Strangler應用程式的步驟是轉化、共存和消除[4]。

轉變--用現代方法創建一個平行的新站點。
共存--讓現有的網站暫時留在原地。從現有的網站重定向到新的網站，這樣功能就可以逐步實現。
消除--從現有網站上刪除舊的功能。

隔板模式
      這種模式將一個應用程式的元素隔離到池中，這樣，如果其中一個發生故障，其他的將繼續運行。這種模式被命名為隔板，因為它類似於船體的分段隔板。根據消費者負載和可用性要求，將服務實例分成不同的組。這種設計有助於隔離故障，並允許你為一些消費者維持服務功能，甚至在故障期間。

Sidecar模式
      這種模式將應用程式的組件部署到一個單獨的處理器容器中，以提供隔離和封裝。這種模式也可以使應用程式由異構的組件和技術組成。這種模式被命名為Sidecar，因為它類似於摩托車上的副車。在該模式中，副車連接到父級應用，併為該應用提供支持功能。側車也與父級應用共用相同的生命周期，與父級應用一起被創建和退役。sidecar模式有時被稱為sidekick模式，是我們在文章中展示的最後一種分解模式。

集成模式
      API網關模式 當一個應用程式被分解成較小的微服務時，有幾個問題需要解決

不同的渠道對多個微服務有多種調用：
有必要處理不同類型的協議。
不同的消費者可能需要不同格式的響應。
API網關有助於解決由微服務實現引起的許多問題，不限於上述問題。

API網關是任何微服務調用的單一入口點：
它可以作為代理服務工作，將請求路由到相關的微服務。
它可以彙總結果，並將其發回給消費者。
這個解決方案可以為每個特定類型的客戶端創建一個細粒度的API。
它還可以轉換協議請求和響應。
它還可以卸載微服務的認證/授權責任。

聚合器模式
當把業務功能分解成幾個較小的邏輯代碼片斷時，就有必要考慮如何協作處理每個服務返回的數據。這個責任不能由消費者來承擔。

Aggregator模式有助於解決這個問題。它講述了我們如何聚合來自不同服務的數據，然後將最終的響應發送給消費者。這可以通過兩種方式完成[6]。

一個複合微服務將調用所有需要的微服務，整合數據，併在發送回之前轉換數據。
API網關也可以將請求分割給多個微服務，併在將數據發送給消費者之前將其彙總。
如果要應用任何業務邏輯，那麼建議選擇一個複合微服務。否則，API網關是既定的解決方案。代理模式的API網關只是通過API網關暴露了微服務。在這個例子中，API網關有三個API模塊。

移動API，它實現了FTGO移動客戶端的API。
瀏覽器API，它實現了在瀏覽器中運行的JavaScript應用程式的API。
公共API，為第三方開發者實現API。

網關路由模式
     API網關負責請求的路由。一個API網關通過將請求路由到相應的服務來實現一些API操作。當它收到一個請求時，API網關會查詢一個路由圖，指定將請求路由到哪個服務。例如，路由圖可以將HTTP方法和路徑映射到服務的HTTP URL。這個功能與NGINX等Web伺服器提供的反向代理功能相同。

鏈式微服務模式
      單個服務或微服務會有多個依賴關係，例如：銷售微服務會依賴產品微服務和訂單微服務。鏈式微服務設計模式將幫助你為你的請求提供綜合結果。

一個微服務收到的請求：1，然後與微服務2進行通信，它可能與微服務3進行通信。所有這些服務都是同步調用。

分支模式
      一個微服務可能需要從多個來源獲得數據，包括其他微服務。Branch微服務模式是Aggregator和Chain設計模式的混合體，允許從兩個或多個微服務同時進行請求/響應處理。被調用的微服務可以是微服務的鏈。分支模式也可用於調用不同的微服務鏈，或根據你的業務需求調用單一的鏈。

客戶端UI組成模式
     當通過分解業務能力/子域來開發服務時，負責用戶體驗的服務必須從幾個微服務中提取數據。在單體世界中，過去只有一個從UI到後臺服務的調用，以檢索所有數據並刷新/提交UI頁面。然而，現在情況就不一樣了。有了微服務，UI必須被設計成一個具有多個部分/區域的屏幕/頁面的骨架。每個部分都會調用一個單獨的後臺微服務來獲取數據。像AngularJS和ReactJS這樣的框架可以很容易地做到這一點。這些屏幕被稱為單頁應用程式（SPA）。每個團隊開發一個客戶端UI組件，如AngularJS指令，為他們的服務實現頁面/屏幕的區域。一個UI團隊負責實現頁面骨架，通過合成多個特定服務的UI組件來構建頁面/屏幕。

資料庫模式
     定義微服務的資料庫架構時，我們需要考慮以下幾點：

服務必須是鬆散耦合的。它們可以被獨立開發、部署和擴展。
業務事務可以執行跨越多個服務的不變性。
一些業務交易需要查詢由多個服務擁有的數據。
資料庫有時必須被覆制和共用，以便進行擴展。
不同的服務有不同的數據存儲要求。

每個服務的資料庫
為瞭解決上述問題，必須為每個微服務設計一個資料庫；它必須是只屬於該服務的。它應該只被微服務的API訪問。它不能被其他服務直接訪問。例如，對於關係型資料庫，我們可以使用private-tables-per-service，schema-per-service，或者database-server-per-service。

每個服務共用資料庫
     我們已經談論過每個服務一個資料庫是微服務的理想選擇。這對微服務來說是一種反模式。但是，如果應用程式是一個單體，並試圖分解成微服務，反規範化就不那麼容易了。在後期階段，我們可以轉到每個服務的資料庫模式。每個服務共用一個資料庫並不理想，但這是上述情況下的工作方案。大多數人認為這是對微服務的反模式，但對於棕地應用來說，這是一個很好的開始，可以將應用分解成更小的邏輯片段。這不應該應用於綠地應用。

命令查詢責任隔離(CQRS)
      一旦我們實現了每個服務的資料庫，就有了查詢的要求，這需要從多個服務中聯合獲取數據，這是不可能的。CQRS建議將應用程式分成兩部分--命令端和查詢端。

命令端處理創建、更新和刪除請求。
查詢端通過使用物化視圖來處理查詢部分。
事件源模式通常與它一起使用，為任何數據變化創建事件。物化的視圖通過訂閱事件流來保持更新。事件源 大多數應用程式都與數據打交道，典型的方法是讓應用程式保持當前狀態。例如，在傳統的創建、讀取、更新和刪除（CRUD）模型中，一個典型的數據過程是從存儲中讀取數據。它包含了鎖定數據的限制，經常使用事務。

事件源模式
      事件源模式定義了一種處理數據操作的方法，該方法由一連串的事件驅動，每一個事件都記錄在一個僅有的存儲器中。應用程式代碼發送一系列的事件，這些事件必須描述發生在數據上的每一個動作，在那裡它們被持久化。每個事件代表了一組對數據的變化（如AddedItemToOrder）。這些事件被持久化在一個作為記錄系統的事件存儲中。事件存儲所發佈的事件的典型用途是維護實體的物化視圖，因為應用程式中的操作改變了它們，並與外部系統集成。例如，一個系統可以維護一個所有客戶訂單的物化視圖，用來填充用戶界面的部分內容。當應用程式添加新的訂單，添加或刪除訂單上的項目，以及添加運輸信息時，描述這些變化的事件可以被處理並用於更新物化視圖。圖中顯示了該模式的概述。

Saga模式
     當每個服務都有自己的資料庫，而一個業務交易跨越多個服務時，我們如何確保跨服務的數據一致性？每個請求都有一個補償性請求，在請求失敗時執行。它可以通過兩種方式實現。

編排（Choreography）--當沒有中央協調時，每個服務產生並監聽另一個服務的事件，並決定是否應該採取某種行動。編排是一種指定兩方或多方的方式；其中沒有任何一方對其他方的流程有任何控制，或者也許對這些流程有任何可見性--可以協調他們的活動和流程以分享信息和價值。當需要跨領域的控制/可見性的協調時，使用編排。在一個簡單的場景中，你可以把編排想成是一個網路協議。它規定了各方之間可接受的請求和響應模式。

協調 - 一個協調者（對象）負責一個傳奇的決策和排序業務邏輯。當你對一個流程中的所有角色都有控制權時，當他們都在一個控制域中，你可以控制活動的流程時。當然，這是最常見的，當你指定一個將在你所控制的一個組織內頒佈的業務流程。

可觀察性模式
      日誌聚合 考慮一個由多個服務組成的應用程式的用例。請求通常跨越多個服務實例。每個服務實例都會以標準化的格式生成一個日誌文件。我們需要一個集中的日誌服務，將每個服務實例的日誌聚合起來。用戶可以搜索和分析這些日誌。他們可以配置警報，當某些消息出現在日誌中時，就會觸發警報。例如，PCF確實有日誌聚合器，它從PCF平臺的每個組件（路由器、控制器、Diego等）和應用程式中收集日誌。AWS Cloud Watch也有同樣的功能。性能指標 當服務組合因微服務架構而增加時，對交易進行監控變得非常關鍵，這樣就可以監控模式，併在問題發生時發出警報。需要一個指標服務來收集關於單個操作的統計數據。它應該聚集一個應用服務的度量，提供報告和警報。有兩種聚合度量的模式。

推送--服務將指標推送給指標服務，例如NewRelic、AppDynamics。
拉--指標服務從服務中提取指標，例如Prometheus。

分散式跟蹤
     在微服務架構中，請求通常跨越多個服務。每個服務通過在多個服務中執行一個或多個操作來處理一個請求。雖然在故障排除中，值得擁有追蹤ID，但我們還是要追蹤一個請求的端到端。解決方案是引入一個交易ID。可以使用以下方法：

給每個外部請求分配一個唯一的外部請求ID。
將外部請求ID傳遞給所有的服務。
在所有的日誌信息中包括外部請求ID。

健康檢查
     當微服務架構被實施後，有可能某個服務已經啟動但無法處理事務。每個服務都需要有一個端點，可以用來檢查應用程式的健康狀況，如健康。這個API應該o檢查主機的狀態，與其他服務/基礎設施的連接，以及任何特定的邏輯。

跨領域的關註模式
     外部配置
一個服務通常也會調用其他服務和資料庫。對於每個環境，如開發、QA、UAT、prod，端點URL或一些配置屬性可能是不同的。這些屬性中的任何一個變化都可能需要重新構建和部署服務。為了避免修改代碼，可以使用配置。將所有配置外部化，包括端點URL和憑證。應用程式應該在啟動時或在運行中載入它們。這些可以在啟動時被應用程式訪問，也可以在不重啟伺服器的情況下被刷新。

服務發現模式
當微服務進入畫面時，我們需要解決在調用服務方面的一些問題。通過容器技術，IP地址被動態地分配給服務實例。每次地址改變時，消費者服務就會中斷，需要手動改變。每個服務的URL都必須被消費者記住，併成為緊耦合的。需要創建一個服務註冊表，它將保存每個生產者服務的元數據和每個服務的規範。一個服務實例在啟動時應向註冊表註冊，在關閉時應取消註冊。有兩種類型的服務發現。

客戶端：例如：Netflix Eureka。
伺服器端：例如。AWS ALB。

斷路器模式
     一個服務通常會調用其他服務來檢索數據，而下游的服務有可能會出現故障。這樣做有兩個問題：第一，請求會一直流向停機的服務，耗盡網路資源，並降低性能。第二，用戶體驗會很差，無法預測。消費者應該通過代理調用一個遠程服務，其行為方式類似於一個斷路器。當連續失敗的次數超過閾值時，斷路器就會跳閘，在超時期間，所有試圖調用遠程服務的嘗試都會立即失敗。超時結束後，斷路器允許有限數量的測試請求通過。如果這些請求成功，斷路器就會恢復正常運行。否則，如果出現了故障，超時期又開始了。這種模式適用於防止應用程式試圖調用遠程服務或訪問共用資源，如果這種操作很可能失敗。

藍綠部署模式
      通過微服務架構，一個應用程式可以有許多微服務。如果我們停止所有的服務，然後部署一個增強的版本，停機時間將是巨大的，並可能影響業務。此外，回滾將是一場噩夢。藍綠部署模式避免了這一點。藍綠部署策略的實施可以減少或消除停機時間。它通過運行兩個相同的生產環境，即藍色和綠色，來實現這一目標。讓我們假設綠色是現有的實時實例，藍色是應用程式的新版本。在任何時候，只有一個環境是實時的，實時環境為所有生產流量服務。所有的雲平臺都提供了實施藍-綠部署的選項。

如有想瞭解更多軟體設計與架構, 系統IT,企業信息化, 團隊管理 資訊，請關註我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。 該文章也同時發佈在我的獨立博客中-Petter Liu Blog。