微服務設計模式心得淺見
微服務是目前相當火紅的軟體/平台架構，有人說它是一種軟體架構風格，它的優點相較於傳統單體式架構，優點在於：
l 每個服務只關注於一個業務功能，將服務單純化。
l 因此，每個微服務可以由不同的開發團隊獨立開發。
l 微服務之間是鬆耦合的，所以可以獨立調整、獨立部署。
l 不同微服務可以使用不同的程式語言進行開發。
l 微服務搭配容器化，可縮短軟體開發的生命週期與提升維運效能。
不過隨著系統內業務功能的不斷增長，導致微服務本身數量的不斷增加或是請求服務的種類內容逐日複雜，原本可正常運作的系統就可能發生效能不佳、微服務之間的藕合度不斷上升，甚至發生系統功能無法服務的情況，倘若在系統架構建立之初，能對微服務的架構與設計模式有一定的認知並加以規劃設計，就可能可以避免掉日後發生的諸多問題。
微服務的架構設計模式目前並沒有所謂的標準定義，巴西軟體工程學者 微服務六大類的設計模式:
1、聚合器微服務設計模式 Aggregator Microservice Design Pattern
2、代理微服務設計模式 Proxy Microservice Design Pattern
3、鏈式微服務設計模式 Chained Microservice Design Pattern
4、分支微服務設計模式 Branch Microservice Design Pattern
5、資料共享微服務設計模式 Shared Data Microservice Design Pattern
6、非同步訊息傳遞微服務設計模式 Asynchronous Messaging Design Pattern
另一軟體工程學者 Madhuka Udantha 則依據微服務可能遇到的問題，匯整定義出可避免或可解決這些問題發生的微服務設計模式，這些設計模式可以歸納成五大類別：
1、拆分模式(Decomposition Patterns)
2、集成模式(Integration Patterns)
3、數據庫模式(Database Patterns)
4、觀察性模式(Observability Patterns)
5、跨领域模式(Cross-Cutting Concern Patterns)
這五大類別所包含的各項設計模式如下圖：
(參考自：https://dzone.com/articles/microservice-architecture-and-design-patterns-for?fromrel=true)
我們從 Madhuka Udantha 提出的五大類別中所屬的各種設計模式，可以歸納出各類別在實務應用上的時機點:
1、拆分模式(Decomposition Patterns)：運用在微服務的服務切分設計上。
2、集成模式(Integration Patterns)：運用在微服務的服務提供與協作方式設計上。
3、數據庫模式(Database Patterns)：運用在微服務資料庫的架構與資料讀取、Transaction策略設計上。
4、觀察性模式(Observability Patterns)：運用在微服務的日誌、問題追蹤、穩定度的設計上。
5、跨领域模式(Cross-Cutting Concern Patterns)：運用在需使用到外部服務與可提供穩定對外服務的設計上。
在我們開始建構微服務平台時，首先遇到的挑戰就是如何將系統的各業務服務，依不同的領域轉換成各個微服務，此時就可參考到Decomposition Patterns的設計理念，進行服務的拆分，而Domain-driven design (DDD) 領域驅動設計則是最常被提出的一種分析設計方式。
當拆分完核心服務、通用服務、支援服務後，接下來就是要架構出微服務的服務提供與微服務之間的協作方式，這也是架構上的核心部份，我們就以 Madhuka Udantha 提出的集成模式(Integration Patterns)來談談這個部份，實務上(我所遇到的)，通常整個的架構方式是揉合了集成模式中的各個模式，如下圖所示：
說明如下：
(1) API Gateway Pattern、Gateway Routing Pattern、Proxy Pattern：
微服務應該提供一個單一入口，或是依不同的前端裝置、不同的系統類別提供不同的單一入口，而這個入口就是API Gateway，API Gateway同時也應具有反向Proxy與服務Routing的功能，這樣的設計除了考慮到安全性，不將服務的真實位址直接暴露給客戶端，也讓用戶端應用程式與內部微服務之間解耦，不會因為內部微服務的調整就必須得調整到客戶端的應用程式。
另外，API Gateway也可以有存取控制、授權、流量控制、監控等功能。
雖然許多功能可以使用既有的軟硬體設備，但API Gateway這個架構概念還是不可缺少。
(2) Aggregator Pattern：
當客戶端需要由服務取得一些資料時(如一個頁面的渲染)，這些資料的資料來源可能包含到數個微服務，並且在取得資料後還需具有邏輯的判斷，此時若由客戶端一一向後端的各微服務發出請求然後再自行處理邏輯判斷，不只效能低下容易出錯，且當有複雜的邏輯需要處理時、資料取得的順序也是個問題，所以若能有一個微服務，聚合了所有需要的資料同時也處理好邏輯判斷，就可以避免可能發生的問題，而這就是Aggregator Pattern。
(3) Chained Microservice Pattern：
一個微服務在提供資料時，資料可以不只是由本身的資料來源所提供，還可以向其它微服務取得資料，而其它的微服務同樣可以再向另外的微服務取得資料，如此，就形成了Chained Microservice Pattern。
以上是對於微服務設計模式的心得淺見，希望可以讓大家對於微服務架構的設計模式有個初步的認識。
