微服務中的設計模式

摘要： 說到設計模式，大家一般會想到，工廠、單例等24種基本設計模式，當然也會想到併發型模式，生產-消費者模式，執行緒池模式等，但是微服務中用到什麼設計模式了？前兩篇介紹了，挎鬥模式和代表模式，當然這一類設計模式屬於雲設計模式。AzureCAT模式和實踐團隊在 Azure架構中心 釋出了九種新的設計...

說到設計模式，大家一般會想到，工廠、單例等24種基本設計模式，當然也會想到併發型模式，生產-消費者模式，執行緒池模式等，但是微服務中用到什麼設計模式了？前兩篇介紹了，挎鬥模式和代表模式，當然這一類設計模式屬於雲設計模式。AzureCAT模式和實踐團隊在 ofollow,noindex" target="_blank">Azure架構中心 釋出了九種新的設計模式。在設計和實現微服務時，這九種模式特別有用。微服務 越來越變的流行是記錄這些模式的動機。

下圖說明了如何在微服務架構中使用這些模式：

對於每種模式，我們都會描述問題，解決方案，何時使用模式以及實現注意事項。

• Ambassador(代表模式) 可用於以一種與語言無關的方式解除安裝常見客戶端連線任務，如監視、記錄、路由、安全（如 TLS）。
• Anti-corruption layer (防損層模式)  實現了新舊應用程式之間的外觀，以確保新應用程式的設計不受遺留系統依賴性的限制。使用此模式可確保應用程式的設計不受限於對外部子系統的依賴。 此模式最先由 Eric Evans 在 Domain-Driven Design（域驅動的設計）中描述。
• Backends for Frontends (用於前端的後端模式) 建立單獨的後端服務，供特定的前端應用程式或介面使用。 要避免為多個介面自定義一個後端時，此模式十分有用。後端為不同型別的客戶端（如桌面和移動裝置）建立單獨的後端服務。這樣，單個後端服務不需要處理各種客戶端型別的衝突要求。通過分離客戶特定的問題，這種模式可以幫助保持每個微服務的簡單性。
• Bulkhead（隔艙模式 ）之所以稱為“隔艙”(Bulkhead)，是因為它類似於船體的分段區。 如果船體受到破壞，只有受損的分段才會進水，從而可以防止船隻下沉。為每個工作負載或服務隔離關鍵資源，例如連線池，記憶體和CPU。通過使用隔板，單個工作負載（或服務）無法消耗所有資源，使其他資源匱乏。此模式通過防止由一個服務引起的級聯故障來提高系統的彈性。
• Gateway Aggregation（閘道器聚合模式） 使用閘道器可將多個單獨請求聚合成一個請求。 當客戶端必須向不同的後端系統發出多個呼叫來執行某項操作時，此模式非常有用使用閘道器可將多個單獨請求聚合成一個請求。 當客戶端必須向不同的後端系統發出多個呼叫來執行某項操作時，此模式非常有用。
• Gateway Offloading（閘道器解除安裝方式） 將共享或專用服務功能解除安裝到閘道器代理。 此模式可以通過將共享服務功能（如 SSL 證書的使用）從應用程式的其他部分移動到閘道器，簡化應用程式開發。
• Gateway Routing（閘道器路由模式） 使用單個終結點將請求路由到多個服務。 如果希望在單個終結點上公開多個服務，並根據請求路由到適當的服務，則此模式非常有用。
• Sidecar（挎鬥模式 ） 將應用程式的幫助程式元件部署為單獨的容器或程序，以提供隔離和封裝。使用此模式還可以使用異構元件和技術來構建應用程式。
• Strangler（絞殺者模式） 通過將特定的功能片斷逐漸取代為新的應用程式和服務，逐步遷移舊系統。 隨著舊系統的功能被替換，新系統最終將取代舊系統的所有功能，抑制舊系統並使其停用。通過逐步用新服務替換特定功能來支援增量遷移。

微服務的目標是通過將應用程式分解為可以獨立部署的小型自治服務來提高應用程式版本的速度。微服務架構也帶來了一些挑戰，這些模式可以幫助緩解這些挑戰。設計模式（design pattern）是對軟體設計中普遍存在（反覆出現）的各種問題，所提出的解決方案。當然微服務中的雲設計模式也是對微服務中普遍存在的問題，所提出的解決方案。我們是工程師，不是碼農，所以小夥伴們，學習一個東西一定要深入一點，勿在浮沙築高層，共勉！

引用：https://azure.microsoft.com/zh-cn/blog/design-patterns-for-microservices/