前面介紹了很多Spring Cloud的組件,本篇按照自己的角度來做一次歸納。
Spring Cloud技術應用從場景上可以分爲兩大類:潤物無聲類和獨挑大樑類。
潤物無聲,融合在每個微服務中、依賴其它組件併爲其提供服務。
- Ribbon,客戶端負載均衡,特性有區域親和、重試機制。
- Hystrix,客戶端容錯保護,特性有服務降級、服務熔斷、請求緩存、請求合併、依賴隔離。Hystrix,客戶端容錯保護,特性有服務降級、服務熔斷、請求緩存、請求合併、依賴隔離。
- Feign,聲明式服務調用,本質上就是Ribbon+HystrixFeign,聲明式服務調用,本質上就是Ribbon+Hystrix
- Stream,消息驅動,有Sink、Source、Processor三種通道,特性有訂閱發佈、消費組、消息分區。Stream,消息驅動,有Sink、Source、Processor三種通道,特性有訂閱發佈、消費組、消息分區。
- Bus,消息總線,配合Config倉庫修改的一種Stream實現,Bus,消息總線,配合Config倉庫修改的一種Stream實現,
- Sleuth,分佈式服務追蹤,需要搞清楚TraceID和SpanID以及抽樣,如何與ELK整合。Sleuth,分佈式服務追蹤,需要搞清楚TraceID和SpanID以及抽樣,如何與ELK整合。
獨挑大樑,獨自啓動不需要依賴其它組件。
- Eureka,服務註冊中心,特性有失效剔除、服務保護。
- Dashboard,Hystrix儀表盤,監控集羣模式和單點模式,其中集羣模式需要收集器Turbine配合。Dashboard.
- Hystrix儀表盤,監控集羣模式和單點模式,其中集羣模式需要收集器Turbine配合。Hystrix儀表盤,監控集羣模式和單點模式,其中集羣模式需要收集器Turbine配合。
- Zuul,API服務網關,功能有路由分發和過濾。
- Config,分佈式配置中心,支持本地倉庫、SVN、Git、Jar包內配置等模式,
每個組件都不是平白無故的產生的,是爲了解決某一特定的問題而存在。
- Eureka和Ribbon,是最基礎的組件,一個註冊服務,一個消費服務。
- Hystrix爲了優化Ribbon、防止整個微服務架構因爲某個服務節點的問題導致崩潰,是個保險絲的作用。
- Dashboard給Hystrix統計和展示用的,而且監控服務節點的整體壓力和健康情況。
- Turbine是集羣收集器,服務於Dashboard的。
- Feign是方便我們程序員些更優美的代碼的。
- Zuul是加在整個微服務最前沿的防火牆和代理器,隱藏微服務結點IP端口信息,加強安全保護的。
- Config是爲了解決所有微服務各自維護各自的配置,設置一個同意的配置中心,方便修改配置的。
- Bus是因爲config修改完配置後各個結點都要refresh才能生效實在太麻煩,所以交給bus來通知服務節點刷新配置的。
- Stream是爲了簡化研發人員對MQ使用的複雜度,弱化MQ的差異性,達到程序和MQ鬆耦合。
- Sleuth是因爲單次請求在微服務節點中跳轉無法追溯,解決任務鏈日誌追蹤問題的。
- 特殊成員Zipkin,之所以特殊是因爲從jar包和包名來看它不屬於Spring Cloud的一員,但是它與Spring Cloud Sleuth的抽樣日誌結合的天衣無縫。乍一看它與Hystrix的Dashboard作用有重疊的部分,但是他們的側重點完全不同。Dashboard側重的是單個服務的統計和是否可用,Zipkin側重的監控環節時長。簡言之,Dashboard側重故障診斷,Ziokin側重性能優化。