微服務架構設計模式
微服務架構需要考慮的問題
- API Gateway
- 服務間調用
- 服務發現
- 服務容錯
- 服務部署
- 數據調用
聚合器微服務設計模式
這是一種最常見也最簡單的設計模式
聚合器調用多個服務實現應用程序所需的功能。它可以是一個簡單的 WEB 頁面，將檢索到的數據進行處理展示。它也可以是一個更高層次的組合微服務，對檢索到的數據增加業務邏輯后進一步發布成一個新的微服務，這符合 DRY 原則。另外，每個服務都有自己的緩存和數據庫。如果聚合器是一個組合服務，那么它也有自己的緩存和數據庫。聚合器可以沿 X軸 和 Z軸 獨立擴展。
代理微服務設計模式
這是聚合模式的一個變種，如下圖所示
在這種情況下，客戶端並不聚合數據，但會根據業務需求的差別調用不同的微服務。代理可以僅僅委派請求，也可以進行數據轉換工作。
鏈式微服務設計模式
這種模式在接收到請求后會產生一個經過合並的響應，如下圖所示
在這種情況下，服務A 接收到請求后會與 服務B 進行通信，類似地，服務B 會同 服務C 進行通信。所有服務都使用同步消息傳遞。在整個鏈式調用完成之前，客戶端會一直阻塞。因此，服務調用鏈不宜過長，以免客戶端長時間等待。
分支微服務設計模式
這種模式是聚合器模式的擴展，允許同時調用兩個微服務鏈，如下圖所示
數據共享微服務設計模式
自治是微服務的設計原則之一，就是說微服務是全棧式服務。但在重構現有的“單體應用（Monolithic Application）”時，SQL 數據庫反規范化可能會導致數據重復和不一致。因此，在單體應用到微服務架構的過渡階段，可以使用這種設計模式，如下圖所示
在這種情況下，部分微服務可能會共享緩存和數據庫存儲。不過，這只有在兩個服務之間存在強耦合關系時才可以。對於基於微服務的新建應用程序而言，這是一種反模式。
異步消息傳遞微服務設計模式
雖然 REST 設計模式非常流行，但它是同步的，會造成阻塞。因此部分基於微服務的架構可能會選擇使用消息隊列代替 REST 請求/響應，如下圖所示
新架構新起點
對於微服務架構，最重要的是思維上的轉變，技術不是問題，思想才是王道（有道無術，術尚可求，有術無道，止於術）
對於做微服務開發的幾點建議：
- 應用程序的核心是業務邏輯，按照業務或客戶需求組織資源（這是最難的）
- 做有生命的產品，而不是項目
- 全棧化
- 后台服務貫徹 Single Responsibility Principle（單一職責原則）
- VM -> Docker -> kubernetes -> lstio (服務網格)
- DevOps -> AIOps