微服務架構設計模式詳解 -5 種主流模式-

大家好，我是 mikechen。

微服務架構是大型網站的必經之路，下面我就全面來詳解 5 大微服務架構設計模式 @mikechen

微服務架構

之前談過微服務是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間採用輕量級的通信機制互相溝通，每個服務都圍繞着具體業務進行構建，並且能夠被獨立地部署到生產環境。

如下圖所示：

爲什麼需要微服務架構

從生產力和系統的複雜性這兩個方面來看，公司一開始的時候，業務複雜性不高，這時候是驗證商業模式的時候，業務簡單，用單體服務反而生產力很高。

如下圖所示：

這種將所有功能，都部署在一個 web 容器中運行的系統，就叫做單體架構，也叫巨石型應用。

單體應用的優點在於：單一架構模式在項目初期很小的時候開發方便，測試方便，部署方便，運行良好。

隨着公司的發展，業務複雜性慢慢提高，以及訪問量越來越大，會出現如下情況：

這時候就可以採用微服務來提升生產力了，這裏就會涉及到微服務架構，以及 5 大微服務架構設計模式。

聚合設計模式

爲了儘量減少服務之間的通信，我們可以使用服務聚合模式。

基本上服務聚合設計模式，是接收來自客戶端、或 API 網關的請求。

然後分配給內部多個後端微服務，再將結果合併，並在一個響應結構中發給請求發起人。

如下圖左側所示：

典型使用，比如：API 網關作爲聚合服務，客戶端只需與 API 網關通信，而不需要直接與各個微服務通信。

這種模式，可以幫助簡化客戶端與微服務之間的通信，並提供更好的性能和用戶體驗。

代理設計模式

代理服務，充當了客戶端、和後端微服務之間的中間層，可以幫助解耦、和增強系統的各種功能。

如下圖左側所示：

比如：

Service Mesh 是一種輕量級的微服務代理框架，用於管理微服務之間的通信。

它通過爲每個微服務注入一個 Sidecar 代理來實現請求的轉發、監控、故障恢復等功能。

異步消息傳遞設計模式

如果通信只是在少數幾個微服務之間進行，那麼同步通信就很好。

但當涉及到多個微服務相互調用，並且要等待一些長時間的操作完成時，我們應該使用異步通信。

雖然 REST 設計模式非常流行，但它是同步的會造成阻塞，因此部分基於微服務的架構，可能會選擇使用消息隊列代替 REST 請求 / 響應。

如下圖所示：

如果你有多個微服務需要彼此交互，而且，你希望這種交互沒有任何依賴性或是松耦合的，那麼我們就應該在微服務架構中使用基於異步消息的通信。

鏈式設計模式

單個服務或者微服務將會有多級依賴，舉個例子：Sale 的微服務依賴 Product 微服務、和 Order 微服務。

在這種情況下，服務 A 接收到請求後會與服務 B 進行通信，類似地，服務 B 會同服務 C 進行通信。

所有服務都使用同步消息傳遞，在整個鏈式調用完成之前，客戶端會一直阻塞。

因此，服務調用鏈不宜過長，以免客戶端長時間等待。

如下圖所示：

數據共享設計模式

我們已經說過，在微服務裏，爲每個服務分配一套單獨的數據庫是理想方案。

採用共享數據庫在微服務裏屬於反模式，但是，如果應用程序是一個單體應用而且試圖拆分成微服務，那麼反正規化就不那麼容易了。

在後面的階段裏，我們可以轉到每個服務一套數據庫的模式，直到我們完全做到了這一點。

但在重構現有的單體應用時，SQL 數據庫反規範化可能會導致數據重複和不一致。

因此，在單體應用到微服務架構的過渡階段，可以使用這種設計模式。

如下圖所示：

在這種情況下，部分微服務可能會共享緩存、和數據庫存儲。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ScT3Pr3Ym0u87pvKk0c5UA

猜你喜歡