概要
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發,如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等,都可以用Spring Boot的開發風格做到一鍵啓動和部署。Spring Cloud並沒有重複製造輪子,它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來,通過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理,最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。
架構
這裏找了一個傳統的SpringCloud的架構圖 架構圖來源
從此圖中我們介紹各個組件之間的說明和功能描述。
- 模塊說明
模塊名 | 說明介紹 |
---|---|
服務治理 | 分爲核心幾塊爲: 1. 服務註冊發現 2. 服務監控 3. 熔點處理 4. 鏈路追蹤 5. 高可用配合中心 依託服務治理 可以很好使 微服務 高可用 |
存儲層 | 各個服務的存儲依託,常見的NOSQL 和 關係SQL 數據庫 以及實時性較高的 時序數據庫 |
服務層 | 服務層 核心分爲如下幾塊: 1. 網關層 用來進行分發和負載均衡 以及權限檢驗 2. 服務之間的連通 (主要有Feign 和 ribbion 2種方式) |
接入層 | 接入層 是外部連入 微服務系統 前 服務器做的 負載均衡、 內容分發網絡、 防止DDOS攻擊、防火牆 等 |
題外話: 微服務的opsdev和 環境發佈 可以使用 Rancher平臺進行有效的管理。
- 組件介紹
組件名 | 說明介紹 | 可替換的第三方組件 |
---|---|---|
config | 通過Git或SVN等版本控制器 存放配置文件 ,拉取遠程地址的配置文件並啓動時加載到系統內 或 同步Bus 更新配置值 | Alibaba-nacos Apollo |
Eureka | 微服務的註冊和發現 ,具有最終一致性 | consul (強一致性)/ zookpeer(強一致性)/ Alibaba-nacos(強一致性) |
BootAdmin | 主要管理服務的健康狀態 、 當前處於活躍狀態的會話數量、當前應用的併發數、延遲以及其他度量信息 | Prometheus + grafana |
hystrix | 熔斷器 和 降級處理 | 暫無 |
turbine | 集羣監控 主要管理hystrix 整合爲一個整體的dashborad | |
sleuth | 服務鏈路追蹤 一般集成Zipkin | |
cloud bus | Spring Cloud Bus 將分佈式的節點用輕量的消息代理連接起來。它可以用於廣播配置文件的更改或者服務之間的通訊,也可以用於監控 | |
cloud stream | Spring Cloud Stream是一個用於構建與共享消息傳遞系統相連的高度可擴展的事件驅動微服務的框架。 | |
cloudTask | SpringCloud的定時任務 | |
zuul | 服務網關 主要有限流 禁止IP 權限資源管理 和 負載均衡 | gateway |
gateway | 服務網關 主要有限流 禁止IP 權限資源管理 和 負載均衡 | zuul |
組件對比
Config VS nacos VS Apollo
微服務配置內容高可用,主要是進行遠程配置文件修改和配置,方便管理生產環境。那我們比對一下現在 最常用的配置中心。 這裏以 spring config 和 alibaba nacos 對比
spring config | alibaba-nacos | Apollo | |
---|---|---|---|
git倉庫管理 | ✔️ | ❌ | ❌ |
可視化界面 | ❌ | ✔️ | ✔️ |
是否支持註冊發現 | ❌ | ✔️ | ❌ |
支持配置環境分割 | ✔️ | ✔️ | ✔️ |
支持灰度發佈 | ❌ | ✔️ | ✔️ |
Spring是否無縫接入 | ✔️ | ✔️ | ❌ |
配置動態變更 | ✔️(繁瑣) | ✔️(簡單) | ✔️(簡單) |
支持集羣 | ✔️ | ✔️ | ✔️ |
性能對比
硬件環境
Nacos和Apollo使用同樣的數據庫(32C128G),部署Server服務的機器使用的8C16G配置的容器,磁盤是100G SSD。
版本
Spring Cloud Config使用2.0.0.M9版本,Apollo使用1.2.0 release版本,Nacos使用0.5版本。
spring config | alibaba-nacos | Apollo | |
---|---|---|---|
單機讀取 | 客戶端限制 7QPS | 15000 QPS | 讀數據庫 7500 QPS 讀內存緩存 9000QPS |
3節點集羣讀取 | 21QPS | 45000 QPS | 內存讀取27000 QPS |
單機寫 | 5QPS | 1800 QPS | 壓滿CPU 1100QPS |
3節點寫 | 5QPS | 6000QPS | 3300 QPS(CPU壓滿) |
備註: 每秒查詢率(QPS,Queries-per-second)是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準
Eureka VS nacos VS consul
CAP 原則
- 一致性(Consistency) (所有節點在同一時間具有相同的數據)
- 可用性(Availability) (保證每個請求不管成功或者失敗都有響應)
- 分隔容忍(Partition tolerance) (系統中任意信息的丟失或失敗不會影響系統的繼續運作)
CAP 無法三者都獲取,因此選擇兩種即可。
alibaba-nacos | Eureka | consul | zookpeer | |
---|---|---|---|---|
一致性協議 | CP+AP | AP | CP | CP |
健康檢查 | TCP/HTTP/MYSQL/Client Beat | Client Beat | TCP/HTTP/gRPC/Cmd | Keep Alive |
負載均衡策略 | 權重/metadata/Selector | Ribbon | Fabio | – |
雪崩保護 | 有 | 有 | 無 | 無 |
自動註銷實例 | 支持 | 支持 | 不支持 | 支持 |
訪問協議 | HTTP/DNS | HTTP | HTTP/DNS | TCP |
監聽支持 | 支持 | 支持 | 支持 | 支持 |
多數據中心 | 支持 | 支持 | 支持 | 不支持 |
跨註冊中心同步 | 支持 | 不支持 | 支持 | 不支持 |
SpringCloud集成 | 支持 | 支持 | 支持 | 不支持 |
Dubbo集成 | 支持 | 不支持 | 不支持 | 支持 |
K8S集成 | 支持 | 不支持 | 支持 | 不支持 |
gateway VS zuul 1.0
spring gateway | zuul 1.0 | |
---|---|---|
spring-cloud-gateway-bench 官方壓測工具 | Requests/sec: 32213.38 | Requests/sec: 20800.13 |
阻塞IO | 非阻塞IO | 阻塞IO |