微服務中的設計模式

          說到設計模式，你們通常會想到，工廠、單例等24種基本設計模式，固然也會想到併發型模式，生產-消費者模式，線程池模式等，可是微服務中用到什麼設計模式了？前兩篇介紹了，挎鬥模式和表明模式，固然這一類設計模式屬於雲設計模式。AzureCAT模式和實踐團隊在 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/