在優銳課的學習分享中，討論了關於微服務的許多設計模式的詳細描述。
碼了很多專業的相關知識， 分享給大家參考學習。
微服務可以對你的企業產生積極影響。 因此，有必要知道如何處理微服務架構（MSA）和一些微服務設計模式，以及微服務架構的一般目標或原理。 這是微服務架構方法[1]中要考慮的四個目標。
降低成本：MSA將降低設計，實施和維護IT服務的總體成本。
提高發布速度：MSA將提高從構思到服務部署的速度。
提高彈性：MSA將提高我們服務網絡的彈性。
啓用可見性：MSA支持可在你的服務和網絡上提供更好的可見性。
你需要了解微服務架構的構建原理
可擴展性
可用性
彈性
靈活性
獨立自主
分散管理
故障隔離
自動配置
通過DevOps連續交付
遵循上述原則，在使你的解決方案或系統付諸實踐的同時，會帶來一些挑戰和問題。 這些問題在許多解決方案中都很常見。 使用正確和匹配的設計模式可以克服這些問題。 微服務有一些設計模式，可以分爲五種模式。 每個都包含許多模式。
分解模式
通過業務能力分解微服務的全部目的是使服務鬆散耦合並應用單一責任原則。 它根據業務能力分解。 定義與業務功能相對應的服務。 業務能力是來自業務體系結構建模的概念[2]。 企業爲了創造價值而要做的事情。 業務能力通常對應於一個業務對象，例如
訂單管理負責訂單
客戶管理對客戶負責
按子域分解
使用業務功能分解應用程序可能是一個不錯的開始，但是你會遇到所謂的“神類”，這很難分解。 這些類將在多種服務中通用。 定義與域驅動設計（DDD）子域相對應的服務。 DDD將應用程序的問題空間（即業務）稱爲域。 一個域由多個子域組成。 每個子域對應於業務的不同部分。 子域可以分類如下：
核心-業務和應用程序最有價值部分的關鍵區別
支持-與業務活動有關，但與差異化無關； 可以在內部實施或外包
通用-不特定於業務，理想情況下使用現成的軟件實施
訂單管理的子域包括
產品目錄服務
庫存管理服務
訂單管理服務
送貨管理服務
按事務分解/兩階段提交（2pc）模式
這種模式可以分解事務上的服務。 然後，系統中將有多個事務。 分佈式事務處理的重要參與者之一是事務處理協調器[3]。 分佈式事務包括兩個步驟：
“準備階段”-“在此階段中，事務的所有參與者都準備提交併通知協調者他們已準備好完成事務
“提交”或“回滾”階段-在此階段，事務協調器向所有參與者發出“提交”或“回滾”命令
2PC的問題在於，與單個微服務的運行時間相比，它相當慢。 即使微服務在同一網絡上，它們之間的事務協調也確實會降低系統速度。 因此通常不會在高負載情況下使用此方法。
扼殺模式
你所經歷的前三個設計模式是分解Greenfield的應用程序，但是你所做的工作中有80％是針對Brownfield應用程序，它們是大型的整體式應用程序（舊版代碼庫）。 扼殺者模式可以解決。 這將創建兩個單獨的應用程序，它們在同一URI空間中並排運行。 隨着時間的流逝，新重構的應用程序會“扼殺”或替換原始應用程序，直到最終，你可以關閉整體應用程序。 Strangler應用程序步驟已轉換，共存並消除[4]：
Transform—使用現代方法創建並行的新站點。
共存—將現有站點保留一段時間。 從現有站點重定向到新站點，以便逐步實現該功能。
消除-從現有站點中刪除舊功能。
隔板圖案
此模式將應用程序的元素隔離到池中，這樣，如果其中一個失敗，其他應用程序將繼續運行。 這種模式被稱爲“艙壁”，因爲它類似於船體的分段分區。 根據使用者負載和可用性要求，將服務實例劃分爲不同的組。 此設計有助於隔離故障，並允許你即使在故障期間仍可爲某些使用者維持服務功能。
邊車圖案
這會將應用程序的組件部署到單獨的處理器容器中，以提供隔離和封裝。 這種模式還可以使應用程序由異構組件和技術組成。 該模式被稱爲Sidecar，因爲它類似於連接到摩托車的Sidecar。 在該模式中，sidecar附加到父應用程序，併爲該應用程序提供支持功能。 Sidecar還與父應用程序共享相同的生命週期，並與父應用程序一起創建並退出。 Sidecar模式有時被稱爲sidekick模式，是我們在文章中顯示的最後一個分解模式。
整合模式
API網關模式當應用程序分解爲較小的微服務時，有一些需要解決的問題API
通過不同的渠道多次調用多個微服務。
需要處理不同類型的協議。
不同的消費者可能需要不同格式的響應。
API網關有助於解決由微服務實現引起的許多問題，而不僅限於上述問題。
API網關是任何微服務調用的單一入口點。
它可以作爲代理服務將請求路由到相關的微服務。
它可以彙總結果以發送回消費者。
此解決方案可以爲每種特定類型的客戶端創建細粒度的API。
它也可以轉換協議請求並做出響應。
還可以減輕微服務的身份驗證/授權責任。
聚合模式
將業務功能分解爲幾個較小的邏輯代碼段時，有必要考慮如何協作每個服務返回的數據。消費者不能承擔這種責任。
聚集器模式有助於解決此問題。它討論瞭如何聚合來自不同服務的數據，然後將最終響應發送給消費者。這可以通過兩種方法來完成[6]：
組合微服務將調用所有必需的微服務，合併數據並轉換數據，然後再發送回去。
API網關還可在將請求發送給使用者之前將請求劃分爲多個微服務並聚合數據。
如果要應用任何業務邏輯，建議選擇複合微服務。否則，API網關是已建立的解決方案。代理模式API網關僅通過API網關公開微服務。在此示例中，
API網關具有三個API模塊：
移動API，可爲FTGO移動客戶端實現API。
瀏覽器API，該API爲瀏覽器中運行的JavaScript應用程序實現該API。
公共API，它爲第三方開發人員實現API。
網關路由模式
API網關負責請求路由。 API網關通過將請求路由到相應的服務來實現一些API操作。 當API網關接收到請求時，它會查詢路由映射，該路由映射指定將請求路由到的服務。 路由映射例如可以將HTTP方法和路徑映射到服務的HTTP URL。 此功能與Web服務器（如NGINX）提供的反向代理功能相同。
鏈式微服務模式
單個服務或微服務將具有多個依存關係，例如：銷售微服務具有依存關係產品微服務和訂單微服務。 鏈接微服務設計模式將幫助你將合併結果提供給你的請求。
微服務：1收到的請求，然後該微服務正在與微服務2通信，並且可能正在與微服務3通信。 所有這些服務都是同步調用。
分支模式
微服務可能需要從包括其他微服務在內的多個來源獲取數據。 分支微服務模式是聚合器和鏈設計模式的混合，並允許來自兩個或多個微服務的同時請求/響應處理。 調用的微服務可以是微服務鏈。 根據你的業務需求，分支模式還可用於調用不同的微服務鏈或單個鏈。
文章寫道這裏，先更上章節，下章節更新出來會第一時間發出來~
喜歡這篇文章的可以點個贊，歡迎大家留言評論，記得關注我，每天持續更新技術乾貨、職場趣事、海量面試資料等等
如果你對java技術很感興趣也可以加入我的java學習羣 V–（ddmsiqi）來交流學習，裏面都是同行，驗證【CSDN2】有資源共享。
不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！
