每個元件都不是平白無故的產生的，是為了解決某一特定的問題而存在。
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側重效能優化。
Spring Cloud各元件總結歸納
spring cloud技術應用從場景上可以分為兩大類 潤物無聲類和獨挑大樑類。潤物無聲，融合在每個微服務中 依賴其它元件並為其提供服務。獨挑大樑，獨自啟動不需要依賴其它元件。每個元件都不是平白無故的產生的，是為了解決某一特定的問題而存在。特殊成員zipkin，之所以特殊是因為從jar包和包名來看它...
springcloud中各元件彙總
a 服務註冊中心 eureka x zookeeper,consul,nacos b 服務呼叫 ribbon,loadbanlancer,feign x openfeign c 服務熔降級 hystrix x resilience4j,sentinel 阿里 d 服務閘道器 zuul x zuul2...
Spring Cloud各元件重試總結
spring cloud中的重試機制應該說是比較混亂的，不同的版本有一定區別，實現也不大一樣，好在spring cloud camden之後已經基本穩定下來，dalston中又進行了一些改進，詳情暫且不表。下面我們來詳細 筆者使用的版本是spring cloud dalston sr4，同樣適應於e...