Spring Cloud 2020.0.0正式發佈，再見了Netflix

時間 2021-01-04

標籤 java 程序員 spring 編程 bootstrap 安全 app 負載均衡框架 dom 欄目 Spring 简体版

原文原文鏈接

分享、成長，拒絕淺藏輒止。關注公衆號【 BAT的烏托邦】，回覆關鍵字 專欄有Spring技術棧、中間件等小而美的 原創專欄供以避免費學習。本文已被 https://www.yourbatman.cn 收錄。

✍前言

你好，我是YourBatman。java

北京時間2020-12-22深夜，Spring Cloud 2020.0.0版本正式發佈。2020.0.0是第一個使用新版本方案的Spring Cloud發行版本。程序員

關於版本號這裏囉嗦幾句：在這以前，Spring Cloud的Release Train名稱採用的是倫敦地鐵站命名方式，如：Hoxton、Greenwich等。spring

說明：2020.0.0版本又名 Ilford（地鐵站名），由於此項目3月後才按照新規改名，估計是爲了團隊內溝通方便吧，你也能夠理解爲它僅是一個內部代號而已，方便溝通

雖按照字母表順序排列，但仍存在兩個致命問題：編程

對非英語母語國家（好比天朝）很是不友好，沒法快速理清版本號關係
A-Z，假若版本號到Z了呢？如何繼續發展？你品，你細品

Spring團隊意識到了這的確是個問題，所以在今年3月份做出了改變。詳情參考我前面寫的一篇文章（強烈建議每一個進來的你都瞭解下此次規則變動）：Spring改變版本號命名規則：此舉對非英語國家很友好bootstrap

說明：版本號規則變動適用於全部Spring技術棧，包含Spring Framework、Spring Boot、Spring Cloud、Spring Data...

文歸正傳。Spring Cloud早在年初就啓動了該版本的研發工做，並在今年4月份就已經發布了其2020.0.0-M1版本（第一個里程碑版本），直到離2020年結束不到10天了才「憋出」大招，正式RELEASE。安全

Spring Cloud做爲構建在Spring Boot之上的雲計算框架，我以爲本次難產的緣由主要有二：app

Spring Boot 2.4.0版本2020-11-12才正式RELEASE（Spirng Framework 5.3.0版本2020-10-27才RELEASE）負載均衡
1. Spring Framework 5.3.0正式發佈，在雲原生路上繼續發力
2. Spring Boot 2.4.0正式發佈，全新的配置文件加載機制（不向下兼容）
改動確實太大，研發、測試、文檔編寫工做量都是巨大的

從Spring Framework、Spring Boot、Spring Cloud三者的發版線路圖再一次驗證了個人那句話：你對Spring Cloud多瞭解源自於你對Spring Boot有多瞭解，你對Spring Boot多瞭解源自於你對Spring Framework有多瞭解。這就是爲什麼我文章花大量筆墨在Spring Framework上而非Spring Boot上的根本緣由，底層通透了，上層運用自如。框架

版本約定

Spring Framework：5.3.2
Spring Boot：2.4.1
Spring Cloud：2020.0.0dom
- 以上版本爲SC「攜帶」的版本

✍正文

有個有趣的現象，截止稿前（2020-12-23 22:00:00）官網還並未同步標註好當前最新版本爲2020.0.0版（如圖）：

其實早在24h以前官方博客就作出了發版宣告：

而且Maven中央倉庫也已存在最新Jar包（證實你正常引包、使用是沒問題的了）：

其實，文檔層面不止官網這一處沒有sync最新版本，我就不一一例舉，畢竟不過重要。針對此現象我yy一下，是否是Spring Cloud團隊缺人人手不夠用呢？請問社招嗎？O(∩_∩)O哈哈~

Spring Cloud版本管理

版本管理對於軟件開發來講過重要，在Spring Boot出現以前依賴關係、版本管理讓人着實頭大（即便有Spring BOM存在），特別是當出現版本不適配時很容易就偷走你一下午甚至一成天的時間。

Spring Cloud做爲上層應用框架，底層版本匹配了才能正常work，其中最主要就是和Spring Boot的版本號要對齊。

與Spring Boot版本對應關係

Spring Boot的出現和流行大大緩解了上述些狀況，但使用起Spring Cloud時它和Spring Boot的版本對應關係依舊是須要特別關注的。爲此我幫你總結出了這個表格：

Release Train	發佈時間	Spring Boot版本	SC Commons版本
2020.0.x	2020-12	2.4.x	3.0.0
Hoxton	2019-07	2.2.x, 2.3.x (從SR5起)	2.2.x
Greenwich	2018-11	2.1.x	2.1.x
Finchley	2017-10	2.0.x	2.0.x
Edgware	2017-08	1.5.x	1.3.x
Dalston	2017-05	1.5.x	1.2.x
Brixton	2016-09	1.3.x	1.1.x
Angel	2016-05	1.2.x	1.0.x

說明：對於Spring Cloud內部組件、Spring Boot、Spirng Framework、Security等這個龐大致系的版本對照關係，文章已整理好，下篇發出，請記得蒐藏哦

特別提醒：spring-cloud-starter-loadbalancer是伴隨着Spring Cloud Commons 2.2.0版本纔開始商用的（Hoxton版本），這個版本節點請稍微關注下，由於它替代了Ribbon。

當前支持的版本

Spring Cloud遵循Pivotal OSS support policy 協議對主要版本提供3年的支持。此外，在Spring Cloud的主要或次要版本發佈後，若存在嚴重的bug和安全問題，就會再維護一段時間（6-12個月不等）。

特別注意：這裏指的 主要版本纔是3年，主要版本可不常有的哦

如今2020.0.0版本已發佈，又到了淘汰的時候。如今Spring Cloud官方還會支持的版本有：

2020.0版本：（支持Spring Boot 2.4.x）它是主要版本，按計劃會支持到2023年12月份
- 它是自Finchley後的又一主要版本
Hoxton版本：（支持Spring Boot 2.2.x和2.3.x）做爲Finchley發行系列的一個次要版本，它的常規維護將持續到2021年6月底。從2020-07開始進入到特殊維護期（不加新功能，只改緊急bug），2021-12月底就只會發佈重大錯誤/安全補丁了
Greenwich版本：（支持Spring Boot 2.1.x）2020-01就中止維護了，2020-12-31號也將終結它的特殊維護期
Finchley版本：（支持Spring Boot 2.0.x）它是一個主要版本的開始，2018年發佈
更老版本：嗯，忘了吧

Spring官方建議：儘可能使用最新版本。不過建議歸建議，做爲只使用晚期大衆技術的咱們，坐在第二排甚至第三排看戲纔有安全感。但歷史的巨浪總歸會把前排淘汰，所以早點作足準備老是好的，不至於時至被推至前排時只能裸泳。

Spring Cloud 2020.0做爲一個主要版本，帶來了衆多顯著的變化，其中進行了一些阻斷式更新（不向下兼容）是本文最大看點，來吧上菜。

阻斷式升級（不向下兼容）

差很少在去年（2019年）的這個時候，Spring Cloud在其Roadmap（以前文章有介紹過）裏就宣佈將要終結的一些庫/版本，其中最重要的就是指Spring Cloud Netflix項目進入維護模式，而後計劃在2020年徹底移除。

Spring Cloud作出這樣的決定其實也是「被迫的」。咱們知道Spring Cloud一直以來把Netflix OSS套件做爲其官方默認的一站式解決方案，那時的Netflix OSS套件巴不得能夠跟Spring Cloud劃等號。奈何呀，Netflix公司在2018年先後宣佈其核心組件Hystrix、Ribbon、Zuul、Archaius等均進入維護狀態。

雖然有Zuul 2.x，Archaius 2.x，但它們均不能向下兼容，沒法平滑升級，所以幾乎等於沒法使用

從2018年至今處於維護狀態的模塊有（包括其對應的starter，此處並未列出）：

spring-cloud-netflix-archaius
spring-cloud-netflix-hystrix-contract
spring-cloud-netflix-hystrix-dashboard
spring-cloud-netflix-hystrix-stream
spring-cloud-netflix-hystrix
spring-cloud-netflix-ribbon
spring-cloud-netflix-turbine-stream
spring-cloud-netflix-turbine
spring-cloud-netflix-zuul

一、再見了，Netflix

時至今日，Spring Cloud 2020.0正式發佈，在這個主要版本里，按既定計劃終於對spring-cloud-netflix動刀了。我幫你畫了幅spring-cloud-netflix-dependencies的xml文件先後版本主要差別的對比圖，一目瞭然：

spring-cloud-netflix-dependencies沒有消失哦，它依舊存在，版本號跟隨大部隊升級爲3.0.x版本
舊版本的spring-cloud-netflix-dependencies管理着Netflix全部組件，包括Hystrix、Ribbon、Zuul、Eureka等。而自2020.0版本起，它有且只管理Eureka（包括Server和Client）

解釋說明：Feign雖然最初屬Netflix公司，但從9.x版本開始就移交給OpenFeign組織管理了，所以再也不劃入Netflix管轄範疇

簡單一句話歸納：Spring Cloud 2020.0.0版本完全刪除掉了Netflix除Eureka外的全部組件。至此，咱們懷着感恩的心能夠對Netflix OSS套件道一聲謝謝，並能夠對它說再見了。

說明：Netflix的Eureka項目仍舊是活躍狀態，這個註冊中心設計上仍是蠻優秀的，綜合表現尚可，市場上競爭力依舊可圈可點，所以Spring Cloud暫還未放棄它

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

Netflix組件替代方案

Spring Cloud既然把Netflix OSS套件大刀闊斧的砍掉了，那總歸得有替代方案吧。那是必然的，Spring Cloud團隊給咱們推薦了用於替代的產品：

Netflix	推薦替代品	說明
Hystrix	Resilience4j	Hystrix本身也推薦你使用它代替本身
Hystrix Dashboard / Turbine	Micrometer + Monitoring System	說白了，監控這件事交給更專業的組件去作
Ribbon	Spring Cloud Loadbalancer	忍不住了，Spring終究親自出手
Zuul 1	Spring Cloud Gateway	忍不住了，Spring終究親自出手
Archaius 1	Spring Boot外部化配置 + Spring Cloud配置	比Netflix實現的更好、更強大

Spring Cloud LoadBalancer是什麼？

以上替代品中，你可能最陌生、最好奇的是Spring Cloud Loadbalancer，它一度只是Spring Cloud 孵化器裏的一個小項目，而且一度擱淺。後再通過重啓，發展，現行使其偉大使命，正式用於徹底替換 Ribbon，成爲Spring Cloud負載均衡器惟一實現。

值得注意的是：Spring Cloud LoadBalancer首次引入是在Spring Cloud Commons 2.2.0時，也就是Hoxton發佈時就引入了，只不過那會還只是備胎/備選，默認依舊是Ribbon挑大樑。下截圖是在Hoxton版本的狀況：

如圖，負載均衡抽象LoadBalancerClient接口有兩個實現，而到了Spring Cloud 2020.0版本後，BlockingLoadBalancerClient就是惟一實現了。

關於spring-cloud-loadbalancer負載均衡器的使用，官方有個極其建議教程： https://spring.io/guides/gs/s...。有興趣可本身玩玩，若沒興趣，那就關注我後面文章分析吧，我會專程介紹它的

Spring Cloud Alibaba是否可做爲替代方案？

嗯，也能夠。

不過它目前來講並非Spring Cloud官方的推薦的默認方案。期待國人一塊兒努力，能早日送Spring Cloud Alibaba上去，讓歪果仁用上咱天朝的框架，提issue必須用中文O(∩_∩)O哈哈~。

顯示導入Netflix包還可否正常work？

既想升級到最新版本的Spring Cloud，又想保持向下兼容使用Netflix的技術。雖然說spring-cloud-netflix-dependencies裏再也不包含netflix的核心組件，那我手動導包並指定版本號行不行？可否正常work呢？

答：我拍腦殼就給你個答案，不行。既然我沒論證過，但這麼使用太畸形了，此方案應被槍斃在萌芽中，不該該有。

另外，今後事也告訴咱們：使用Spring Cloud時儘可能面向它的抽象編程，這樣即便Spirng Cloud換底層組件（如換熔斷器、負載均衡器）等等，理論上對咱們業務是無影響或者影響很小的，這都得益於它的Spring Cloud Commons抽象，那裏是精華。

二、Bootstrap上下文默認再也不啓動

知曉原理的同窗知道，Spring Cloud容器是靠Bootstrap Context引導上下文來啓動的，對應的類是BootstrapApplicationListener。

這在2020.0版本發生了改變，新版本的Spring Cloud再也不依賴於此上下文而啓動。所以默認狀況下，將再也不啓動Bootstrap上下文。代碼層面的改變發生在這裏：

BootstrapApplicationListener：

    @Override
    public void onApplicationEvent(ApplicationEnvironmentPreparedEvent event) {
        ConfigurableEnvironment environment = event.getEnvironment();
        // 在方法開頭加了這麼個判斷
        if (!bootstrapEnabled(environment) && !useLegacyProcessing(environment)) {
            return;
        }
        ...
    }

PropertyUtils：

    // BOOTSTRAP_ENABLED_PROPERTY = spring.cloud.bootstrap.enabled
    public static boolean bootstrapEnabled(Environment environment) {
        return environment.getProperty(BOOTSTRAP_ENABLED_PROPERTY, Boolean.class, false) || MARKER_CLASS_EXISTS;
    }
    // USE_LEGACY_PROCESSING_PROPERTY = spring.config.use-legacy-processing
    public static boolean useLegacyProcessing(Environment environment) {
        return environment.getProperty(USE_LEGACY_PROCESSING_PROPERTY, Boolean.class, false);
    }

開啓方式

若你須要開啓Bootstrap上下文，有兩種辦法能夠實現：

設置值spring.cloud.bootstrap.enabled=true或者 spring.config.use-legacy-processing=true便可。注意：這些個屬性值必須確保其能放進環境裏才能生效。好比靠譜的方式是：系統屬性、環境變量、命令行等
引入一個Jar：org.springframework.cloud:spring-cloud-starter-bootstrap，而後什麼都不用作了
1. 說明：這個jar裏面有且僅有一個Marker類，做用你懂的，此處不作過多解釋

說明：手動開啓Bootstrap上下文，證實你fallback到老的方式去加載SC，那麼一切請按照老方式作便可

三、全新的配置方式

得益於Spring Boot 2.4.x支持全新的配置文件書寫方式，自此可使用spring.config.import倆導入其它組建的配置。如：

spring.config.import=configserver:xxx
spring.config.import=zookeeper:
...

這麼作更具模塊化，更符合雲原生環境的要求。

四、其它

以前若要禁用Spring Cloud Config Client端的健康指示用的是health.config.enabled=false，現改成management.health.config.enabled=false。保持了和Spring Boot控制端點風格一致
帶有無效字符(破折號)的端點id已經改成符合標準的了，自此啓動時再也沒有討厭的警告了，拯救潔癖者。
- bus-env -> busenv
- bus-refresh -> busrefresh
- service-registry -> serviceregistry

// old
@Endpoint(id = "service-registry")
public class ServiceRegistryEndpoint { ... }

// new
@Endpoint(id = "serviceregistry")
public class ServiceRegistryEndpoint { ... }

常規式升級

常規升級這塊關注點就沒那麼多了，主要對其組件如Spring Cloud Commons、Spring Cloud Kubernetes、Spring Cloud Openfeign...等作些常規升級，乏善可陳。

值得關注的一點：Spirng Cloud全部的Module版本號均升級到了3.0.0（大版本號的升級），除Spring Cloud Circuitbreaker/Spring Cloud Kubernetes（2.0.0）和Spring Cloud Task（2.3.0）以外。

仍舊存在的問題

雖然2020.0已經RELEASE了，可是仍存在着未解決的問題，例舉幾個此版本現存的問題：

若使用spring.config.import=configserver:來配置配置中心，此版本漏掉了支持retry參數
- 解決方案：若你要使用的話，你只得fallback到傳統方式嘍（寫在bootstrap.yaml裏）
spring-cloud-config-dependencies裏出現了一個非release版本的jar（具體看下截圖）
- 解決方案：手動指定該jar的版本號

說明：M1屬於里程碑版本，還屬於較爲早起階段，可能存在bug，建議你使用時手動指定版本號替換掉這個jar

看來即便強如Spring團隊，也會出現各類各樣的紕漏呀。這麼一想的話，我又敢放心大膽的回去寫bug去嘍。

✍總結

Spring Cloud 2020.0.0是Spring Cloud的主要版本，是很是重要的存在，升級、改變也是巨大的。特別體如今Netflix模塊的所有移除、Spring Cloud啓動方式變了等等。伴隨着Spring Boot 2.4.x以及Spirng Cloud 2020.0的發佈，而且棄用Netflix OSS套件後，必將走入一個新的深度編程體驗，滿懷驚喜，非常期待。

說明：由於此版本徹底擯棄掉了Netflix的一套東西，爲了跟上時代，我會使用一段時間後，儘快寫出最新版本的系列教程，助你少踩坑

文末有提到2020.0版本雖已發佈，但仍舊存在些問題。不過話說回來，那些都屬於很小的問題，可能在下個小版本里就獲得修復。但尷尬的是，距離2020年結束只有不到10天了，假若進入到了2021年，按照版本號命名新規，彼時發出的版本將不能再叫2020.x.x而只能是2021.x.x，顯然這就屬於大版本號的迭代了，須要謹慎啊。

你以爲Spring Cloud團隊在2020年還會發版嗎？歡迎在評論區留下你的見解。