微服務設計模式（下）

問題

如何為微服務定義資料庫體系結構是一個問題。以下是需要解決的問題：

1. 服務必須鬆散耦合。它們可以獨立地開發、部署和擴充套件。

2. 業務事務可能強制跨多個服務的不變數。

3. 一些業務事務需要查詢由多個服務擁有的資料。

4. 資料庫有時必須複製和切分，以便進行擴充套件。

5. 不同的服務有不同的資料儲存需求。

解決方案

為了解決上述問題，每個微服務必須設計一個資料庫;這項服務必須是私人的。它只能由microservice API訪問。其他服務不能直接訪問它。例如，對於關聯式資料庫，我們可以使用針對服務的私有表、針對服務的模式或針對服務的資料庫-伺服器。每個微服務都應該有一個單獨的資料庫id，以便能夠提供單獨的訪問，以設定障礙，並防止它使用其他服務表

問題

我們已經討論過，每個服務有一個資料庫對於微服務來說是理想的，但是當應用程式是greenfield並且可以用DDD開發時，這是可能的。但如果應用程式是一個整體，並試圖進入微服務，反規範化不是那麼容易。在這種情況下，什麼是合適的體系結構？

解決方案

每個服務共享資料庫並不理想，但這是上述場景的有效解決方案。大多數人認為這是一種針對微服務的反模式，但對於棕地應用程式來說，這是將應用程式分解為更小的邏輯部分的良好開端。這不應該應用於綠地應用。在這種模式中，一個資料庫可以與多個微服務對齊，但必須限制在2-3個最大值，否則，伸縮性、自主性和獨立性將難以執行。

問題

一旦我們實現了每個服務的資料庫，就需要進行查詢，這需要來自多個服務的聯合資料——這是不可能的。那麼，我們如何在微服務體系結構中實現查詢呢？

解決方案

CQRS建議將應用程式分為兩部分——命令端和查詢端。命令端處理建立、更新和刪除請求。查詢端透過使用物化檢視來處理查詢部分。事件源模式通常用於為任何資料更改建立事件。物化檢視透過訂閱事件流來保持更新。

問題

當每個服務都有自己的資料庫和跨越多個服務的業務事務時，我們如何確保服務之間的資料一致性?例如，對於客戶有信用限額的電子商務應用程式，應用程式必須確保新訂單不會超過客戶的信用限額。由於訂單和客戶位於不同的資料庫中，應用程式不能簡單地使用本地ACID事務。

解決方案

Saga代表由幾個子請求組成的高階業務流程，每個子請求在一個服務中更新資料。當請求失敗時，每個請求都有一個補償請求執行。它可以透過兩種方式實現：

1. 編排——當沒有中央協調時，每個服務產生並監聽另一個服務的事件，並決定是否應該採取行動。

2. 編配——編配者(物件)負責傳奇的決策制定和業務邏輯的排序。

問題

考慮一個用例，其中應用程式由在多臺機器上執行的多個服務例項組成。請求通常跨越多個服務例項。每個服務例項以標準化格式生成一個日誌檔案。我們如何透過日誌瞭解特定請求的應用程式行為？

解決方案

我們需要一個集中的日誌記錄服務來聚合來自每個服務例項的日誌。使用者可以搜尋和分析日誌。它們可以配置當日志中出現某些訊息時觸發的警報。例如，PCF確實有Loggeregator，它從PCF平臺的每個元件(路由器、控制器、diego等)以及應用程式中收集日誌。AWS雲表也做了同樣的事情。

問題

當由於微服務體系結構而導致的服務組合增加時，對事務進行監視就變得非常重要，以便在出現問題時可以監視模式併傳送警報。我們應該如何收集指標來監控應用程式效能？

解決方案

需要一個度量服務來收集關於單個操作的統計資訊。它應該聚合提供報告和警報的應用程式服務的指標。聚合度量有兩種模型：

1. 推送——服務將指標推送到指標服務，例如NewRelic, AppDynamics

2. Pull - 度量服務從服務中提取度量指標，例如Prometheus

問題

在微服務體系結構中，請求通常跨越多個服務。每個服務透過跨多個服務執行一個或多個操作來處理請求。那麼，我們如何跟蹤端到端請求來解決問題呢？

解決方案

我們需要一種服務

• 分配每個外部請求一個唯一的外部請求id。

• 將外部請求id傳遞給所有服務。

• 在所有日誌訊息中包含外部請求id。

• 記錄在集中服務中處理外部請求時執行的請求和操作的資訊(例如，開始時間、結束時間)。

Spring Cloud Slueth以及Zipkin server都是通用實現。

問題

當實現了微服務體系結構時，服務可能會啟動，但無法處理事務。在這種情況下，如何確保請求不會轉到那些失敗的例項？使用負載平衡模式實現。

解決方案

每個服務都需要有一個端點，可以用來檢查應用程式的健康狀況，比如/health。這個API應該檢查主機的狀態、到其他服務/基礎設施的連線以及任何特定的邏輯。

Spring Boot Actuator 確實實現了一個/health端點，並且該實現也可以自定義。

問題

服務通常也呼叫其他服務和資料庫。對於開發、QA、UAT、prod等每個環境，端點URL或某些配置屬性可能不同。任何這些屬性的更改都可能需要重新構建和重新部署服務。如何避免對配置更改進行程式碼修改？

解決方案

外部化所有配置，包括端點url和憑證。應用程式應該在啟動或執行時載入它們。

Spring Cloud config server提供了將屬性外部化到GitHub並將其作為環境屬性載入的選項。應用程式可以在啟動時訪問它們，也可以在不重啟伺服器的情況下重新整理它們。

問題

當微服務出現的時候，我們需要解決一些關於呼叫服務的問題：

1. 使用容器技術，IP地址被動態分配給服務例項。每次地址更改時，使用者服務可能會中斷，並需要手動更改。

2. 每個服務URL都必須被使用者記住併成為緊密耦合的。

那麼消費者或路由器如何知道所有可用的服務例項和位置呢？

解決方案

需要建立一個服務註冊中心，以儲存每個生產者服務的後設資料。服務例項在啟動時應該註冊到註冊中心，在關閉時應該登出註冊。使用者或路由器應查詢登錄檔並找出服務的位置。註冊中心還需要對生產者服務進行健康檢查，以確保只有服務的工作例項可以透過它使用。有兩種型別的服務發現:客戶端和伺服器端。客戶端發現的一個例子是Netflix Eureka，伺服器端發現的一個例子是AWS ALB。

問題

服務通常呼叫其他服務來檢索資料，下游服務可能會停機。這樣做有兩個問題：首先，請求將繼續使用down服務，耗盡網路資源並降低效能。其次，使用者體驗將是糟糕的和不可預測的。如何避免級聯服務故障並優雅地處理故障？

解決方案

使用者應該透過代理呼叫遠端服務，代理的行為類似於斷路器。當連續故障數超過閾值時，斷路器跳閘，在超時期間，所有呼叫遠端服務的嘗試都會立即失敗。超時過期後，斷路器允許有限數量的測試請求透過。如果這些請求成功，斷路器將恢復正常工作。否則，如果出現故障，超時週期將再次開始。

Netflix Hystrix是斷路器模式的良好實現。它還可以幫助您定義一個備用機制，可以使用斷路器跳閘。這提供了更好的使用者體驗。

問題

使用微服務體系結構，一個應用程式可以有許多微服務。如果我們停止所有服務，然後部署一個增強版本，停機時間將是巨大的，並可能影響業務。此外，回滾將是一場噩夢。我們如何避免或減少部署期間服務的停機時間？

解決方案

可以實現藍綠色部署策略以減少或消除停機時間。它透過執行兩個相同的生產環境(藍色和綠色)來實現這一點。讓我們假設綠色是現有的活動例項，藍色是應用程式的新版本。在任何時候，只有一個環境是live, live環境服務於所有生產流量。所有云平臺都提供了實現藍綠色部署的選項。

與微服務體系結構一起使用的還有許多其他模式，比如Sidecar、鏈式微服務、分支微服務、事件源模式、持續交付模式等等。隨著我們在微服務方面獲得更多的經驗，這個名單還在不斷增長。我現在停下來是為了瞭解您正在使用的微服務模式。