在優銳課的學習分享中，討論了關於微服務的許多設計模式的詳細描述。
碼了很多專業的相關知識， 分享給大家參考學習。
看到這裏迷路的朋友們可以先看本文的上部分內容，這樣思路更清晰！
微服務的設計模式（一）
客戶端UI組合模式
通過分解業務功能/子域來開發服務時，負責用戶體驗的服務必須從多個微服務中提取數據。 在整體世界中，從UI到後端服務只有一次調用，以檢索所有數據並刷新/提交UI頁面。 但是，現在不一樣了。 對於微服務，必須將UI設計爲具有屏幕/頁面的多個部分/區域的框架。 每個部分都將調用單個後端微服務以提取數據。 諸如AngularJS和ReactJS之類的框架可以輕鬆地做到這一點。 這些屏幕稱爲單頁應用程序（SPA）。 每個團隊都開發一個客戶端UI組件，例如AngularJS指令，該組件實現其服務的頁面/屏幕區域。 UI團隊負責通過組合多個特定於服務的UI組件來實現構建頁面/屏幕的頁面框架。
數據庫模式
在定義微服務的數據庫架構時，我們需要考慮以下幾點。
服務必須鬆散耦合。 它們可以獨立開發，部署和擴展。
商業交易可能會強制涉及多個服務的不變式。
一些業務交易需要查詢多個服務擁有的數據。
有時必須複製和共享數據庫才能進行擴展。
不同的服務具有不同的數據存儲要求。
每個服務的數據庫
爲了解決上述問題，必須爲每個微服務設計一個數據庫。 它必須僅對該服務專用。 只能由微服務API訪問它。 其他服務無法直接訪問它。 例如，對於關係數據庫，我們可以使用每個服務專用表，每個服務架構或每個服務數據庫服務器。
每個服務共享數據庫
我們已經討論了每個服務一個數據庫是微服務的理想選擇。 它是微服務的反模式。 但是，如果應用程序是一個整體並且試圖闖入微服務，那麼非規範化就不那麼容易了。 在後面的階段中，我們可以按服務模式轉移到DB。 每個服務共享數據庫不是理想的選擇，但這是上述情況的可行解決方案。 大多數人認爲這是微服務的反模式，但對於棕地應用程序，這是將應用程序分解成較小邏輯部分的一個很好的開始。 這不應應用於未開發的應用
命令查詢職責隔離（CQRS）
一旦我們實現了每個服務的數據庫，就需要進行查詢，這需要來自多個服務的聯合數據。 這是不可能的。 CQRS建議將應用程序分爲兩部分-命令側和查詢側。
命令行處理創建，更新和刪除請求。
查詢端通過使用實例化視圖來處理查詢部分。
通常將事件源模式與它一起使用來爲任何數據更改創建事件。 通過訂閱事件流，可以使實例化視圖保持更新。 事件源大多數應用程序都使用數據，典型的方法是使應用程序保持當前狀態。 例如，在傳統的創建，讀取，更新和刪除（CRUD）模型中，典型的數據處理是從存儲中讀取數據。 它包含經常使用事務鎖定數據的限制。
事件來源模式
Event Sourcing模式[8]定義了一種方法，用於處理由一系列事件驅動的數據上的操作，每個事件都記錄在僅追加存儲中。應用程序代碼向事件存儲發送一系列事件，這些事件命令性地描述對數據執行的每個操作，並在事件存儲中保留它們。每個事件代表一組數據更改（例如，AddedItemToOrder）。這些事件將保留在充當記錄系統的事件存儲中。事件存儲發佈的事件的典型用途是在應用程序中的動作更改實體時維護實體的實體化視圖，以及與外部系統集成。例如，系統可以維護用於填充UI部分的所有客戶訂單的實例化視圖。當應用程序添加新訂單，添加或刪除訂單中的項目以及添加運輸信息時，可以處理描述這些更改的事件並將其用於更新實例化視圖。該圖顯示了該模式的概述。
事件採購模式[8]
傳奇模式
當每個服務都有自己的數據庫並且一個業務事務跨越多個服務時，我們如何確保各個服務之間的數據一致性？ 每個請求都有一個補償請求，該請求在請求失敗時執行。 它可以通過兩種方式實現：
編排-如果沒有中央協調，則每個服務都會生成並偵聽另一個服務的事件，並決定是否應採取措施。編排是一種指定兩個或多個參與方的方式。它們都無法控制對方的流程，或者對這些流程的任何可見性-都無法協調其活動和流程以共享信息和價值。當需要跨控制/可見性域進行協調時，請使用編排。在簡單的場景中，你可以想到編排，就像網絡協議一樣。它規定了各方之間可接受的請求和響應模式。
傳奇模式—編舞
編排-編排（對象）負責傳奇的決策和業務邏輯排序。當你控制流程中的所有參與者時。當它們全部處於一個控制範圍內時，你可以控制活動的流程。當然，這通常是當你指定將在你擁有控制權的一個組織內製定的業務流程時。
賢者模式—編排
可觀察性模式
日誌聚合考慮一個用例，其中一個應用程序包含多個服務。請求通常跨越多個服務實例。每個服務實例均以標準化格式生成日誌文件。我們需要一個集中式日誌記錄服務，該服務可以彙總每個服務實例的日誌。用戶可以搜索和分析日誌。他們可以配置在某些消息出現在日誌中時觸發的警報。例如，PCF確實具有Log Aggregator，它從PCF平臺的每個組件（路由器，控制器，diego等）收集日誌，並附帶應用程序。 AWS Cloud Watch也這樣做。性能指標當服務組合由於微服務體系結構而增加時，監視交易變得至關重要，以便可以監視模式並在發生問題時發送警報。需要度量服務來收集有關單個操作的統計信息。它應該聚合提供報告和警報的應用程序服務的指標。有兩種用於彙總指標的模型：
推送-服務將指標推送到指標服務，例如NewRelic，AppDynamics。
Pull-指標服務從服務中提取指標，例如普羅米修斯。
分佈式跟蹤
在微服務架構中，請求通常跨越多個服務。 每個服務通過跨多個服務執行一個或多個操作來處理請求。 在進行故障排除時，值得擁有跟蹤ID，但我們會端對端跟蹤請求。 解決方案是引入交易ID。 可以採用跟隨方式；
爲每個外部請求分配唯一的外部請求ID。
將外部請求ID傳遞給所有服務。
在所有日誌消息中包括外部request-id。
健康檢查
實施微服務架構後，服務可能會啓動但無法處理事務。 每個服務都需要具有一個可用於檢查應用程序運行狀況（例如運行狀況）的終結點。 該API應該o檢查主機的狀態，與其他服務/基礎結構的連接以及任何特定的邏輯
交叉切割關注模式
服務通常還會調用其他服務和數據庫。 對於開發，質量檢查，UAT，產品等每個環境，端點URL或某些配置屬性可能會有所不同。 這些屬性中的任何一個更改都可能需要重新構建和重新部署服務。 爲避免代碼修改，可以使用配置。 外部化所有配置，包括端點URL和憑據。 應用程序應該在啓動時或運行時加載它們。 這些可以在啓動時由應用程序訪問，也可以在不重新啓動服務器的情況下進行刷新。
服務發現模式
當微服務出現時，我們需要在調用服務方面解決一些問題。 使用容器技術，IP地址可以動態分配給服務實例。 每次地址更改時，消費者服務都會中斷，需要手動更改。 消費者必須記住每個服務URL，並使其緊密耦合。 需要創建一個服務註冊表，該註冊表將保留每個生產者服務的元數據和每個規範的規範。 服務實例在啓動時應註冊到註冊表，而在關閉時應註銷。 服務發現有兩種類型：
客戶端：例如：Netflix Eureka。
服務器端：例如：AWS ALB。
服務發現[9]
斷路器模式
一個服務通常調用其他服務來檢索數據，並且下游服務可能會關閉。這樣做有兩個問題：首先，請求將繼續進入服務中斷狀態，耗盡網絡資源，並降低性能。其次，用戶體驗將是糟糕且不可預測的。消費者應通過代理來調用遠程服務，該代理的行爲與斷路器相似。當連續的故障數超過閾值時，斷路器會跳閘，並且在超時期間內，所有調用遠程服務的嘗試都會立即失敗。超時到期後，斷路器將允許有限數量的測試請求通過。如果這些請求成功，則斷路器將恢復正常運行。否則，如果發生故障，則超時時間將再次開始。如果此操作很有可能失敗，則此模式適用於防止應用程序嘗試調用遠程服務或訪問共享資源。
斷路器模式[10]
藍綠色部署模式
使用微服務架構，一個應用程序可以具有許多微服務。 如果我們停止所有服務，然後部署增強版本，則停機時間將是巨大的，並可能影響業務。 同樣，回滾將是一場噩夢。 藍綠色部署模式可以避免這種情況。 可以實施藍綠色部署策略以減少或消除停機時間。 它通過運行兩個相同的生產環境Blue和Green來實現這一目標。 假設Green是現有的活動實例，Blue是該應用程序的新版本。 在任何時候，只有一個環境處於活動狀態，該活動環境爲所有生產流量提供服務。 所有云平臺均提供用於實施藍綠色部署的選項。
喜歡這篇文章的可以點個贊，歡迎大家留言評論，記得關注我，每天持續更新技術乾貨、職場趣事、海量面試資料等等
如果你對java技術很感興趣也可以加入我的java學習羣 V–（ddmsiqi）來交流學習，裏面都是同行，驗證【CSDN2】有資源共享。
不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！
