微服務架構和設計模式 - DZone微服務

banq發表於2019-07-27
微服務架構設計模式

微服務可以對您的企業產生積極影響。因此，值得了解如何處理微服務架構（MSA）和微服務的一些設計模式以及微服務架構的一般目標或原則。

分解模式
1. 按業務能力分解
微服務是關於使服務鬆散耦合，應用單一責任原則。它們由業務功能分解，並定義與業務功能相對應的服務。業務能力是業務架構建模的概念。這是企業創造價值的東西。業務能力通常對應於業務物件，例如

  • 訂單管理負責訂單。
  • 客戶管理負責客戶。

2.按子域/有界上下文分解
使用業務功能分解應用程式可能是一個良好的開端，但是您會遇到所謂的“上帝類”，它不容易分解。這些類在多個服務中很常見。域驅動設計（DDD）是指應用程式的問題空間 - 業務 - 作為域。域由多個子域組成，每個子域對應於業務的不同部分。
子域名可分為以下幾類：
  • 核心 - 業務的關鍵差異化因素和應用程式中最有價值的部分。
  • 支援 - 與業務有關，但與差異化無關。這些可以在內部實施或外包。
  • 通用 - 不是特定於業務，理想情況下使用現成的軟體實現。

訂單管理的子域/有界上下文包括：
  • 產品目錄服務。
  • 庫存管理服務。
  • 訂單管理服務。
  • 送貨管理服務。

3. 按事務/兩階段提交（2PC）模式分解
您可以透過事務分解服務，然後系統中將有多個事務。分散式事務的重要參與者之一是事務協調器[3]。分散式事務包括兩個步驟：
  • 準備階段 - 在此階段，交易的所有參與者都準備提交併通知協調員他們已準備好完成交易。
  • 提交或回滾階段 - 在此階段，事務協調器向所有參與者發出提交或回滾命令。

2PC的問題在於，與單個微服務的操作的執行時間相比，它非常慢。協調微服務之間的事務，即使它們位於同一網路上，也會降低系統速度，因此這種方法通常不用於高負載情況。

扼殺者模式
上面這三種設計模式在分解綠地應用程式的應用程式時使用，但是你所做的80％的工作是使用大型棕地應用程式單片應用程式（遺留程式碼庫）。扼殺者模式在這裡得到了拯救。這將建立兩個獨立的應用程式，它們在同一URI空間中並排存在。隨著時間的推移，新重構的應用程式“扼殺”或替換原始應用程式，直到您最終關閉整體應用程式。Strangler應用程式步驟是轉換，共存和消除：

  • 轉換 - 使用現代方法建立並行的新站點。
  • 共存 - 將現有站點保留一段時間。從現有站點重定向到新站點，以便逐步實現功能。
  • 消除 - 從現有站點中刪除舊功能。

Bulkhead模式
將應用程式的元素隔離到池中，以便在其中一個失敗時，其他元素將繼續執行。這種模式稱為Bulkhead，因為它類似於船體的分段分割槽。根據使用者負載和可用性要求，將分割槽服務例項拆分為不同的組。此設計有助於隔離故障，並允許您為某些消費者維持服務功能，即使在故障期間也是如此。

邊車模式
將應用程式的元件部署到單獨的處理器容器中以提供隔離和封裝。此模式還可以使應用程式由異構元件和技術組成。這種模式被稱為Sidecar，因為它類似於連線到摩托車的邊車。在該模式中，邊車附加到父應用程式併為應用程式提供支援功能。sidecar還與父應用程式共享相同的生命週期，與父項一起建立和退役。邊車模式有時被稱為搭檔模式。

微服務的整合模式
1.API閘道器模式
當應用程式分解為較小的微服務時，需要解決一些問題：

  • 不同渠道有多個微服務呼叫。
  • 需要處理不同型別的協議。
  • 不同的消費者可能需要不同的響應格式。

API閘道器有助於解決微服務實現引起的許多問題，而不僅限於上述問題。
  • API閘道器是任何微服務呼叫的單一入口點。
  • 它可以作為代理服務將請求路由到相關的微服務。
  • 它可以聚合結果以發回給消費者。
  • 此解決方案可以為每種特定型別的客戶端建立細粒度的API。
  • 它還可以轉換協議請求並進行響應。
  • 它還可以解除安裝微服務的身份驗證/授權職責。

2. 聚合模式
在將業務功能分解為幾個較小的邏輯程式碼片段時，有必要考慮如何協作每個服務返回的資料。這種責任不能留給消費者。聚合器模式有助於解決這個問題。它討論了我們如何聚合來自不同服務的資料，然後將最終響應傳送給消費者。這可以透過兩種方式完成：
  1. 複合微服務將呼叫所有必需的微服務，合併資料，並在發回之前轉換資料。
  2. API閘道器還可以將請求分割槽為多個微服務，並在將資料傳送給消費者之前對其進行聚合。

建議如果要應用任何業務邏輯，則選擇複合微服務。否則，API閘道器是已建立的解決方案。

3.代理模式
我們只是透過API閘道器公開微服務，API閘道器有三個API模組：
  • 移動API - 實現FTGO移動客戶端的API
  • 瀏覽器API - 實現在瀏覽器中執行的JavaScript應用程式的API
  • 公共API - 為第三方開發人員實現API

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

鏈式微服務模式
對於單個服務或微服務將存在多個依賴性，例如：銷售微服務具有依賴性產品微服務和訂單微服務。鏈式微服務設計模式將幫助您為您的請求提供綜合結果。微服務1收到的請求，然後與微服務-2通訊，它可能與微服務-3通訊。所有這些服務都是同步呼叫。

分支模式
微服務可能需要從多個源（包括其他微服務）獲取資料。分支微服務模式是聚合器和鏈設計模式的混合，允許來自兩個或更多微服務的同時請求/響應處理。呼叫的微服務可以是微服務鏈。Brach模式還可用於根據您的業務需求呼叫不同的微服務鏈或單個鏈。

客戶端UI組合模式
當透過分解業務能力/子域來開發服務時，負責使用者體驗的服務必須從幾個微服務中提取資料。在整體世界中，過去只有一次從UI到後端服務的呼叫來檢索所有資料並重新整理/提交UI頁面。但現在，它將不一樣。使用微服務，UI必須設計為具有螢幕/頁面的多個部分/區域的骨架。每個部分都會呼叫一個單獨的後端微服務來提取資料。像AngularJS和ReactJS這樣的框架有助於輕鬆完成。這些螢幕稱為單頁應用程式（SPA）。每個團隊都開發了一個客戶端UI元件，例如AngularJS指令，它實現了服務的頁面/螢幕區域。

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

  • 服務必須鬆散耦合。它們可以獨立開發，部署和擴充套件。
  • 業務事務可以強制執行跨多個服務的不變數。
  • 某些業務事務需要查詢由多個服務擁有的資料。
  • 有時必須複製資料庫並按比例共享。
  • 不同的服務有不同的資料儲存要求。

1.每個服務一個資料庫
為了解決上述問題，必須設計每個微服務一個資料庫; 它必須僅對該服務是私有的。它應該僅由微服務API訪問。其他服務無法直接訪問它。例如，對於關聯式資料庫，我們可以使用每服務私有表，每服務模式或每服務資料庫伺服器。

2.每個服務共享資料庫
我們已經討論過每個服務一個資料庫是微服務的理想選擇。它是微服務的反模式。如果應用程式是一個整體，並試圖打破微服務，非規範化並不那麼容易。每個服務的共享資料庫並不理想，但這是可行的解決方案。大多數人認為這是微服務的反模式，但對於棕色應用程式，這是將應用程式分解為更小的邏輯部分的良好開端。這不應該適用於綠地應用。

3.命令查詢責任分離（CQRS）
一旦我們實現了每服務資料庫，就需要進行查詢，這需要來自多個服務的聯合資料。這是不可能的。CQRS建議將應用程式分為兩部分 - 命令端和查詢端。

  • 命令端處理建立，更新和刪除請求。
  • 查詢端使用例項化檢視處理查詢部分。

事件源模式通常與其一起使用，以建立任何資料更改的事件。透過訂閱事件流來保持物化檢視的更新。

4.事件溯源
大多數應用程式使用資料，典型的方法是讓應用程式保持當前狀態。例如，在傳統的建立，讀取，更新和刪除（CRUD）模型中，典型的資料過程是從商店讀取資料。它包含鎖定資料的限制，通常使用事務。
Event Sourcing模式定義了一種處理由一系列事件驅動的資料操作的方法，每個事件都記錄在一個僅附加儲存中。應用程式程式碼傳送一系列事件，這些事件強制性地將資料上發生的每個操作描述到事件儲存中，並儲存在事件儲存中。每個事件代表一組對資料的更改（例如AddedItemToOrder）。
事件儲存在充當記錄系統的事件儲存中。事件儲存釋出的事件的典型用途是在應用程式中的操作更改它們以及與外部系統整合時維護實體的物化檢視。例如，系統可以維護用於填充UI部分的所有客戶訂單的物化檢視。當應用程式新增新訂單，新增或刪除訂單上的專案並新增送貨資訊時，可以處理描述這些更改的事件並使用它們來更新實體化檢視。

5.Saga模式
當每個服務都有自己的資料庫並且業務事務跨越多個服務時，我們如何確保跨服務的資料一致性？每個請求都有一個在請求失敗時執行的補償請求。它可以透過兩種方式實現：
  • Choreography  - 沒有中央協調器，每個服務產生並監聽另一個服務的事件並決定是否應該採取行動。編排是一種指定兩方或多方的方式; 其中任何一方都無法控制其他方的流程，或者可能對這些流程有任何可見性 - 可以協調其活動和流程以共享資訊和價值。當需要跨控制/可見性域協調時，請使用編排。在簡單的場景中，您可以將編排想象為網路協議。它規定了各方之間可接受的請求和響應模式。
  • Orchestration - 一箇中央協調器orchestrator（物件）負責saga的決策制定和業務邏輯排序。當你控制程式中的所有actor時。當他們都在一個控制領域，你可以控制活動的流程。當然，這通常是在您指定將在您可以控制的一個組織內部制定的業務流程時。


觀察模式
1.日誌聚合
考慮一個應用程式由多個服務組成的用例。請求通常跨越多個服務例項。每個服務例項都以標準化格式生成日誌檔案。我們需要一個集中式日誌記錄服務來聚合來自每個服務例項的日誌。使用者可以搜尋和分析日誌。他們可以配置在日誌中顯示某些訊息時觸發的警報。例如，PCF確實有一個Log聚合器，它從PCF平臺的每個元件（路由器，控制器，Diego等）以及應用程式收集日誌。AWS Cloud Watch也是如此。

2.效能指標
當服務組合由於微服務架構而增加時，監視事務變得至關重要，以便可以監視模式並在問題發生時傳送警報。
需要度量服務來收集有關各個操作的統計資訊。它應聚合應用程式服務的度量標準，該服務提供報告和警報。聚合指標有兩種模型：

  • 推送 - 服務將指標推送到指標服務，例如NewRelic，AppDynamics
  • 拉 - 指標服務從服務中提取指標，例如Prometheus


3. 分散式跟蹤
在微服務架構中，請求通常跨越多個服務。每個服務透過跨多個服務執行一個或多個操作來處​​理請求。在進行故障排除時，值得擁有跟蹤ID，我們會端到端跟蹤請求。
解決方案是引入一個事務ID，可以使用以下方法;
  • 為每個外部請求分配唯一的外部請求ID。
  • 將外部請求ID傳遞給所有服務。
  • 在所有日誌訊息中包含外部請求ID。

4.健康檢查
當實施微服務架構時，服務可能會啟動但無法處理事務。每個服務都需要有一個端點，可用於檢查應用程式的執行狀況，例如執行狀況。此API應檢查主機的狀態，與其他服務/基礎結構的連線以及任何特定邏輯。

跨領域關注模式
1. 外部配置
服務通常也會呼叫其他服務和資料庫。對於dev，QA，UAT，prod等每個環境，端點URL或某些配置屬性可能不同。任何這些屬性的更改都可能需要重新構建和重新部署服務。
為避免程式碼修改，可以使用配置。外部化所有配置，包括端點URL和憑據。應用程式應在啟動時或動態載入它們。這些可以在啟動時由應用程式訪問，也可以在不重新啟動伺服器的情況下重新整理。

2. 服務發現模式
當微服務出現時，我們需要解決一些關於呼叫服務的問題。
使用容器技術，IP地址可動態分配給服務例項。每次地址更改時，消費者服務都可能中斷並需要手動更改。
每個服務URL都必須由消費者記住並緊密耦合。
需要建立一個服務登錄檔，它將保留每個生產者服務和規範的後設資料。服務例項應在啟動時註冊到登錄檔，並在關閉時登出。有兩種型別的服務發現：

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


3. 斷路器模式
服務通常呼叫其他服務來檢索資料，並且下游服務可能會關閉。這有兩個問題：首先，請求將繼續執行下行服務，耗盡網路資源並降低效能。其次，使用者體驗將是糟糕且不可預測的。
消費者應該透過代理來呼叫遠端服務，代理的行為類似於電路斷路器。當連續故障的數量超過閾值時，斷路器跳閘，並且在超時時間段內，所有呼叫遠端服務的嘗試都將立即失敗。超時到期後，斷路器允許有限數量的測試請求透過。如果這些請求成功，則斷路器恢復正常操作。否則，如果發生故障，則超時時間再次開始。此模式適用於阻止應用程式嘗試呼叫遠端服務或訪問共享資源（如果此操作很可能失敗）。


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

 

相關文章