## 一、Spring Cloud與Netflix Netflix是一家做視頻網站的公司，之所以要說一下這個公司是因為Spring Cloud在發展之初，Netflix做了很大的貢獻。包括服務注冊中心Eureka、服務調用Ribbon、Feign，服務容錯限流Hystrix、服務網關Zuul等眾多組件都是Netflix貢獻給Spring Cloud社區的。 但這些組件在使用過程中也多多少少的暴露了一些弊病，比如： * 服務網關Zuul是基于servlet開發的，使用阻塞IO，在高并發情況下性能表現一般。 * 公共服務組件過多，部署一個Spring Cloud微服務，公共服務組件就占用了很多的服務器資源。 所以，很多的廠商就基于Spring Cloud設計理念，開發自己的組件，其中比較著名的就是Spring Cloud Alibaba和攜程的apollo。  上圖中綠色對號的基本上都是Spring Cloud社區第二代組件，也是目前建議使用的組件。圖中紅色X號的組件，都基本上面臨著淘汰與替換。 ## 二、核心事件追蹤 筆者一直關心著Spring Cloud社區的發展，下面將近兩年社區的大事件集中展現一下： * 2018年6月底，Eureka 2.0 開源工作宣告停止，繼續使用風險自負。 * 2018年11月底，Hystrix 宣布不再在開源版本上提供新功能。 * 2018年12月，Spring官方宣布Netflix的相關項目進入維護模式（Maintenance Mode）。 從此，Spring Cloud逐漸告別netflix時代。 * 2018年10月31日，Spring Cloud Alibaba正式入駐了Spring Cloud官方孵化器，并在maven中央庫發布了第一個版本。 與此同時，Spring Cloud團隊內部維護的組件也在積極的更新換代。 ## 二、服務注冊中心選型 * Eureka：Spring Cloud與Netflix的大兒子，出生的時候家里條件一般，長大后素質有限。 * Nacos：后起之秀，曾經Spring Cloud眼中“別人家的孩子”，已經納入收養范圍（Spring Cloud Alibaba孵化項目）。 * Apache Zookeeper：關系戶，與hadoop關系比較好 * etcd：關系戶，與kubernetes關系比較好 * Consul：關系戶，曾經與docker關系比較好 如果你的應用已經使用到了hadoop、kubernetes、docker，在Spring Cloud實施過程中可以考慮使用其關系戶組件，避免搭建兩套注冊中心，節省資源。但是二者兼容使用說說容易，真正用起來還需要功夫。目前看，筆者覺得最佳選擇應該是Nacos。 ## 三、分布式配置管理 目前可選的分布式配置管理中心，有阿里的Nacos、攜程的Apollo、和Spring Cloud Config。 * 如果你希望完成單純的分布式配置集中管理，其實三者都能滿足你的需求。 * 如果你考慮到已經用Nacos實現了服務注冊中心，不想單獨搞出來一個配置管理中心，合二為一的話，nacoos可能是你的最佳選擇 * 攜程的Apollo與nacos很多相似之處，有頗多的亮點。從筆者的使用感受而言，目前apollo從文檔細節到方便度要好于nacos（截止2020年4月）。但是nacos畢竟開源時間較短，依托alibaba的支持，有很大的潛力和發展空間。 * spring cloud config對比其他兩者，在功能以及友好度方面都遜色。唯一的優點可能是它比較輕量級。 | 對比項目/配置中心 | spring cloud **config** | **apollo** | **nacos(重點)** | | --- | --- | --- | --- | | 開源時間 | 2014.9 | 2016.5 | 2018.6 | | 配置實時推送 | 弱支持（Spring Cloud Bus） | 支持（HTTP長輪詢1s內） | 支持（HTTP長輪詢1s內） | | 版本管理 | 支持（Git） | 自動管理 | 自動管理 | | 配置回滾 | 弱支持（Git+Bus） | 支持 | 支持 | | 配置的灰度發布 | 理念上支持，可操作性不強 | 支持 | 1.1.0開始支持 | | 權限管理 | 不支持（沒有區分用戶、角色、權限的概念） | 支持 | 1.2.0開始支持 | | 多集群多環境 | 對集群概念支持較弱 | 支持 | 支持 | | 多語言 | 只支持Java | Go,C++,Python,Java,.net,OpenAPI | Python,Java,Nodejs,OpenAPI | | 分布式高可用最小集群數量 | **Config**\-Server2+Git+MQ | **Config**2+Admin3+Portal\*2+Mysql=8 | **Nacos**\*3+MySql=4 | | 配置格式校驗 | 不支持 | 支持 | 支持 | | 通信協議 | HTTP和AMQP | HTTP | HTTP | | 數據一致性 | Git保證數據一致性，**Config**\-Server從Git讀取數據 | 數據庫模擬消息隊列，**Apollo**定時讀消息 | HTTP異步通知 | ## 三、服務網關 服務網關這塊就不多說了，沒有任何懸念，Spring Cloud Gateway在各方面都碾壓Zuul，Zuul2也基本上是胎死腹中。還有一些第三方廠商開發的微服務網關，但基本上沒有形成氣候！ ## 四、熔斷限流 #### Hystrix 2018年12月，Spring官方宣布Netflix的相關項目進入維護模式（Maintenance Mode）。不再開發新的功能，但是Hystrix整體上還是比較穩定的，對于老用戶不必更換，影響也不大。 #### resilience4j Hystrix停更之后，Netflix官方推薦使用resilience4j（https://github.com/resilience4j/resilience4j ），它是一個輕量、易用、可組裝的高可用框架，支持熔斷、高頻控制、隔離、限流、限時、重試等多種高可用機制。 #### Sentinel（重點） Sentinel（https://github.com/alibaba/Sentinel ）是阿里中間件團隊開源的，面向分布式服務架構的輕量級高可用流量控制組件，主要以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度來幫助用戶保護服務的穩定性。 https://github.com/alibaba/Sentinel/wiki/Guideline:-%E4%BB%8E-Hystrix-%E8%BF%81%E7%A7%BB%E5%88%B0-Sentinel |Sentinel | Hystrix | resilience4j | | --- | --- | --- | | 隔離策略 | 信號量隔離（并發線程數限流） | 線程池隔離/信號量隔離 | 信號量隔離 | | 熔斷降級策略 | 基于響應時間、異常比率、異常數 | 基于異常比率 | 基于異常比率、響應時間 | | 實時統計實現 | 滑動窗口（LeapArray） | 滑動窗口（基于 RxJava） | Ring Bit Buffer | | 動態規則配置 | 支持多種數據源 | 支持多種數據源 | 有限支持 | | 擴展性 | 多個擴展點 | 插件的形式 | 接口的形式 | | 基于注解的支持 | 支持 | 支持 | 支持 | | 限流 | 基于 QPS，支持基于調用關系的限流 | 有限的支持 | Rate Limiter | | 流量整形 | 支持預熱模式、勻速器模式、預熱排隊模式 | 不支持 | 簡單的 Rate Limiter 模式 | | 系統自適應保護 | 支持 | 不支持 | 不支持 | | 控制臺 | 提供開箱即用的控制臺，可配置規則、查看秒級監控、機器發現等 | 簡單的監控查看 | 不提供控制臺，可對接其它監控系統 |