微服務架構的構件原創
扼殺者模式
它們是傳統、龐大的單體應用。扼殺者模式爲此而生。這種模式會創建兩個獨立的應用,一同運行在同樣的 URI 空間中。隨着時間點的推移,新的重構了的應用會扼殺或者替換掉原有應用,最後就可以關掉單體應用了。這種模式分爲 轉換、共存 和 終結 三個步驟
單體你繼續運營者, 我慢慢把你替換掉
艙壁模式
這個模式把應用的元素隔離開來,這樣一個失敗之後,其它的還能繼續工作。這個模式可以類比船體結構,因此被稱爲艙壁。根據消費者的負載以及可用性要求,把服務分割爲不同的羣。這種設計能夠對故障進行隔離,即使遇到故障,也能爲部分消費者提供服務
注: 艙壁模式(Bulkhead)隔離了每個工作負載或服務的關鍵資源,如連接池、內存和 CPU,使用艙壁避免了單個工作負載(或服務)消耗掉所有資源,從而導致其他服務出現故障的場景,這種模式主要是通過防止由一個服務引起的級聯故障來增加系統的彈性(艙壁模式降低依賴服務對整個系統的影響,保護有限的資源不被耗盡,增加了系統得到彈性)
Sidecar 模式
這種模式把應用的組件部署到一個不同的容器中,從而更好地完成隔離和封裝。這種模式讓應用能夠把多種組件和技術整合在一起。這種模式的情況很像摩托車的挎鬥,因此被稱爲 Sidecar,Sidecar 附着在主應用上,並且爲主應用提供支持能力。Sidecar 還和主應用共享同樣的生命週期,它的創建和銷燬都是和主應用同步進行的。Sidecar 模式有時也被稱爲 Sidekick 模式
栗子: 我在開發中需要做日誌收集, 我可以給你的業務而外加裝 日誌收集等等, 就像吃雞的3輪摩托一樣, 而外的座位就是加裝過來的,丟了也沒事,不影響業務.
集成模式
API 網關模式
應用被分解成更小的微服務之後,就會出現一些待解決的問題
- 如何處理來自不同渠道的不同微服務的調用
- 如何處理不同的協議
- 不同消費者可能需要不同格式的響應
API 網關就是用來處理這類問題的
- API 網關是所有微服務調用的單一入口
- 可以作爲代理服務器,將特定請求路由到特定微服務
- 可以把調用結果進行聚合,發回給消費者
- 可以爲每種類型的客戶端創建細粒度的 API
- 還能轉化請求和響應的協議
- 可以代微服務進行認證、鑑權的工作
聚合模式
業務功能被分拆爲多個更小的代碼段之後,如何把各個微服務返回的數據進行整合就是個問題了。這種責任不應該拋給消費者自行解決。聚合模式可以解決這種問題,這種模式的關鍵是如何把多個不同服務的響應數據進行聚合,然後將最終響應發回給消費者。可以用兩種方式來完成任務:
- 用一個複合微服務調用所有必須的微服務,把數據拼裝成合適的結果發回給客戶端
- 用 API 網關把請求拆分爲對多個微服務的調用,然後聚合返回結果發回給客戶端
如果這一過程中有業務邏輯,推薦使用複合微服務的方式。其它情況下,API 網關是個好方法
前臺-中臺-後臺 中外就是聚合模式
代理模式
對外的 API 網關
對內的 API 網關
這種 API 網關只會使用 API 網關開放微服務。例如一個 API 網關有三個 API 模塊:
- 移動 API: 爲手機客戶端提供 API
- 瀏覽器 API: 爲瀏覽器中運行的 JavaScript 應用提供 API
- 公共 API: 爲第三方開發者提供的 API
大範圍栗子: 小程序用一套API, APP用一套API, 網頁用一套API
小範圍栗子: 按照功能去劃分API
路由網關模式
這種 API 網關負責對請求進行路由。它通過將請求路由給特定服務的方式來完成 API 調用。當它接到請求的時候,會根據請求在路由表中查找合適的服務。舉個例子來說,路由表可能會將一個 HTTP 方法和路徑映射爲服務的 HTTP URL。這種能力和 NGINX 等服務器的反向代理功能一致
鏈式微服務模式
有的微服務會有多種依賴,例如銷售服務依賴於產品和訂單服務。鏈式微服務模式能夠爲請求提供合併的結果,微服務 1 收到的請求會向後傳遞給微服務 2 和微服務 3。所有這些服務都是同步調用
A調用B調用C
客戶端分解模式
說白了就是前後分離的開發模式
數據庫模式
在微服務中定義數據庫架構,需要考慮幾個要點:
- 服務必須鬆耦合。可以獨立的被開發、部署以及擴縮容
- 業務事務可能需跨越多個服務
- 有的業務事務需要查詢隸屬於多個服務的多種數據
- 數據庫必須能夠被複制或者共享從而滿足規模要求
- 不同服務有不同的數據存儲需求
服務獨佔數據庫
爲了滿足上述要素,每個服務必須擁有各自的數據庫;數據庫必須被特定服務所獨佔。對這些獨佔數據是不能直接訪問的,只能通過微服務 API 進行數據訪問。例如關係型數據庫來說,可以用服務專屬的數據表、專屬結構或者專屬數據庫
服務共享數據庫
微服務領域的理想情況就是每個服務都獨佔數據庫。那麼共享數據庫就是反模式的。但是在單體應用拆分爲微服務的過程中可就沒那麼容易了。後面的階段中,可以轉向每個服務獨佔數據庫的模式。共享數據庫並不理想,但是在遷移過程中是有用的。多數人會認爲這不符合微服務需求,但是對於既有應用,這是一個好的拆分起點。綠地應用就不該這樣了
命令查詢隔離
命令和查詢的隔離 (CQRS),一旦實現了服務獨佔數據的模式,就有了拼接多個服務的數據的需要。CQRS 把應用分成兩部分 —— 命令和查詢
命令端用來處理創建、更新和刪除
查詢端用物化視圖來處理查詢
事件源模式會爲任何數據變更創建事件。物化視圖訂閱事件流,以此來保持更新。事件源模式的典型用法就是根據數據來管理應用程序的當前狀態。例如傳統的增刪改查模型是從存儲讀取數據的。這其中存在鎖定數據的需要,通常要用事務來解決
就是,讀取是讀取的服務,寫是寫的服務
事件源模式
也就是異步通訊,每一次事件都走消息隊列
Saga 模式
簡單的說就是 去中心化和中心化兩種感覺
一種主動請求(主動),一種訂閱請求(被動)
觀察模型
日誌聚合
日誌聚合針對的是包含多個服務的應用。請求經常會跨越多個服務實例。每個服務實例都生成標準格式的日誌文件。我們需要一箇中央日誌服務,把各個服務實例的日誌聚合起來。用戶可以對日誌進行搜索和分析。可以對日誌系統進行配置,如果出現了特定信息,就觸發告警。例如 PCF 的日誌聚合器會從 PCF 的每個組件(router、controller、diego 等)和應用中搜集日誌。AWS 的 Cloud Watch 也做了同樣的事情
性能指標
微服務架構下服務數量會急劇增加,就需要提高監控的重視程度,在問題發生時,才能及時的發送警報。需要有一個度量服務來收集各種統計信息。應用提供的報告和告警都應該發送給這個服務。聚合指標有兩種模型:
推: 服務把指標推送給監控服務,例如 NewRelic、AppDynamics
拉: 監控服務自行拉取指標數據,例如 Prometheus
分佈式追蹤
微服務架構下,請求經常會跨越多個服務。每個服務又要用一個或多個操作,調用多個服務來處理請求。要對請求進行端到端的跟蹤,有個跟蹤 ID 會非常有幫助。可以用下列方法來引入事務 ID 從而解決這一問題:
- 爲每個外部請求分配一個唯一的外部請求 ID
- 把外部請求的 ID 傳遞到所有服務
- 在所有日誌信息中輸出這一外部的請求 ID
健康檢查
實現了微服務架構之後,微服務自身可能出現無法處理業務的情況。每個服務都需要有一個端點,用來檢查應用的健康情況。這個 API 可以檢查主機的狀態、到其它服務、基礎設施的連接情況,以及一些別的邏輯
跨領域模式
外部化配置
服務通常會調用其它服務以及數據庫。多個環境中,例如開發、測試、生產等,端點地址或者一些配置屬性可能不同。這些屬性中的任何變動都可能需要服務的重新構建和部署。爲了這種情況,建議使用外部配置,例如 URL 和登錄憑據。應用應該在啓動時或者隨時載入配置
就像nocas的配置中心
服務發現模式
就像是 Eureka Nocas 等等服務中心
熔斷模式
大家都懂熔斷器, 阿里的Sentinel、 netflix的 Hystrix
藍綠部署模式
在微服務架構中,一個應用會由多個服務構成,如果停掉所有服務,部署一個增強版本,停機時間會對業務造成很大影響。同樣回滾過程也會是一個噩夢。藍綠部署模式避免了這種問題。藍綠部署的策略能夠降低或免除服務的停機時間。這種策略同時運行兩個一致的生產環境,用這種方式來解決問題。假設綠色是現存的服務實例,而藍色是新版本。任何時間裏,只有一個環境是在線的,這個在線環境會處理所有生產通信。所有的雲平臺都提供了藍綠部署的支持