微服務是大型架構的必經之路，也是大廠重點考察對象，下面我就重點詳解4大主流微服務架構方案。

1、微服務聚合模式

微服務聚合設計模式，解決了如何從多個微服務中聚合數據，以便客戶端可以獲得所需的完整信息，而不需要多次請求不同的服務。

此類模式主要用于簡化客戶端的操作，減少與多個微服務交互的復雜性。

如下圖所示：

通過構建一個聚合服務（又稱聚合層或聚合微服務），將多個微服務的響應數據進行聚合，形成一個統一的結果返回給客戶端。

聚合服務，通過調用多個微服務的 API，收集它們的響應并進行整合。

優點：

• 簡化客戶端請求：客戶端只需調用聚合服務，不需要直接與多個微服務交互。
• 減少服務間依賴：聚合服務可以減輕微服務之間的耦合度，服務間可以獨立變化。

缺點：

• 聚合服務可能成為性能瓶頸，需特別關注聚合服務的可擴展性。
• 如果聚合的服務很多，可能需要額外的處理來確保高效聚合。

2、微服務共享模式

微服務提倡的是：每個服務擁有自己的獨立數據庫（比如：數據庫獨立性原則），以確保服務之間的高內聚性、和低耦合性。

然而，在某些情況下，由于業務需求或技術限制，多個微服務可能需要共享數據。

如下圖所示：

實際上在微服務架構的初期階段，很多企業可能會采用 共享數據庫 模式，來簡化系統的開發和維護，尤其是在微服務遷移的過渡階段。

這樣做雖然簡化了架構，但卻違反了微服務的原則，因為它導致了微服務之間的緊密耦合。

因此，“共享數據庫”模式通常被視為“過渡性”或“反模式”，不是長期推薦的設計。

3、微服務代理模式

微服務代理是一種中間層，用于處理服務之間的通信。

如下圖所示：

在這種模式下，代理服務充當了其他微服務的代理，接收客戶端的請求并將其轉發給后端服務進行處理。

在 Sidecar 代理模式 中，Sidecar 是與每個微服務實例配對部署的。
每個微服務實例旁邊都有一個獨立的代理進程，這些代理共同組成一個統一的服務網格。

代理負責捕獲并管理服務的入站和出站流量。代理通常會與服務網格的 控制平面 交互，獲取流量路由、負載均衡、訪問策略等配置。

優點：

• 解耦：客戶端和微服務之間的交互通過代理服務來處理。
• 統一入口：所有請求都經過代理，易于管理、監控和控制。

缺點：

• 代理服務需要額外的資源來處理請求，可能成為性能瓶頸。

4、微服務異步消息模式

異步消息設計模式，在微服務架構中非常重要，它允許微服務通過消息隊列、事件流等方式進行松散耦合的通信。

如下圖所示：

微服務通過發布事件來通知其他服務發生了某個狀態變化。事件通常是業務變化或數據變化的通知，例如：訂單創建、支付成功…等。

優點：

• 服務解耦：服務之間不需要直接調用，只有事件通知機制。
• 提高吞吐量：通過異步處理，減少了服務的同步依賴。

缺點：

• 事件的順序和一致性需要額外考慮，容易出現“事件丟失”或“消息重復消費”的問題。