微服務架構的六種模式
- 微服務架構模式方案
用 Scale Cube 方法設計應用架構，將應用服務按功能拆分成一組相互協作的服務。每個服務負責一組特定、相關的功能。每個服務可以有自己獨立的數據庫，從而保證與其他服務解耦。
1.1 聚合器微服務設計模式
聚合器調用多個服務實現應用程序所需的功能。它可以是一個簡單的 Web 頁面，將檢索到的數據進行處理展示。它也可以是一個更高層次的組合微服務，對檢索到的數據增加業務邏輯後進一步發佈成一個新的微服務，這符合 DRY 原則。另外，每個服務都有自己的緩存和數據庫。如果聚合器是一個組合服務，那麼它也有自己的緩存和數據庫。聚合器可以沿 X 軸和 Z 軸獨立擴展。
1.2 代理微服務設計模式
這是聚合器模式的一個變種，在這種情況下，客戶端並不聚合數據，但會根據業務需求的差別調用不同的微服務。代理可以僅僅委派請求，也可以進行數據轉換工作。
1.3 鏈式微服務設計模式
這種模式在接收到請求後會產生一個經過合併的響應，在這種情況下，服務 A 接收到請求後會與服務 B 進行通信，類似地，服務 B 會同服務 C 進行通信。所有服務都使用同步消息傳遞。在整個鏈式調用完成之前，客戶端會一直阻塞。因此，服務調用鏈不宜過長，以免客戶端長時間等待。
1.4 分支微服務設計模式
這種模式是聚合器模式的擴展，允許同時調用兩個微服務鏈
1.5 數據共享微服務設計模式
自治是微服務的設計原則之一，就是說微服務是全棧式服務。但在重構現有的 “單體應用（monolithic application）” 時，SQL 數據庫反規範化可能會導致數據重複和不一致。因此，在單體應用到微服務架構的過渡階段，可以使用這種設計模式
1.6 異步消息傳遞微服務設計模式
雖然 REST 設計模式非常流行，但它是同步的，會造成阻塞。因此部分基於微服務的架構可能會選擇使用消息隊列代替 REST 請求 / 響應
作者：duanxz
來源：https://www.cnblogs.com/duanxz/p/3514895.html
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/QwzTx1TapU_7DWDd-hy-UQ