技術文章 » SpringCloud怎麼邁向雲原生？

SpringCloud怎麼邁向雲原生？

2022-10-27 12:02:15

很多公司由於歷史原因，都會有自研的RPC框架。

尤其是在2015-2017期間，Spring Cloud剛剛面世，Dubbo停止維護多年，很多公司在設計自己的RPC框架時，都會基於Spring Cloud做二次開發。並且會大量使用Spring Cloud Netflix相關的模組與程式碼。

因此，我們去梳理一下Spring Cloud的前世今生，以及未來雲原生髮展的趨勢，可以給這些RPC框架的演進帶來一些啟發。

1、Spring Cloud的歷史

Spring Cloud 自 2015 年 3 月推出之後，很快就在 Java 微服務生態中，成為開發人員的首選技術棧。

 

Spring Cloud 在 Spring Boot 的基礎上，保留 Java 開發習慣，加入分散式特性，提供了一系列通用工具來幫助開發者在分散式系統裡快速構建一些常見模式，現在已成為使用範圍最廣的微服務架構之一。

Spring Cloud提供了微服務開發所需的設定管理、服務發現、斷路器、智慧路由、叢集狀態管理等元件。最重要的是，跟Spring Boot框架一起使用的話，會讓你開發微服務架構非常方便。

Spring Cloud本身不是新的框架，它是一系列框架的有機組合，利用Spring Boot的開發便利性巧妙地簡化了分散式系統基礎設施的開發。

注意，並非所有元件都由Spring提供，Netflix扮演了重要的角色。註冊中心Eureka、熔斷器Hystrix、負載均衡元件Ribbon、閘道器Zuul等重要元件均由Netflix提供，主要貢獻來自 Netflix OSS。

2、Spring Cloud的現在

由於Netflix在開源投入上的策略調整，Eureka、Hystrix、Ribbon 相繼宣佈停止維護，社群上人心惶惶，因為當時絕大部分開發者認為 Spring Cloud = Spring Cloud Netflix。

但實際上 Spring Cloud 是一套規範，這套規範並不是只有 Netflix OSS，還有 Spring Cloud Alibaba，Spring Cloud Zookeeper，Spring Cloud Consul，Spring Cloud Kubernetes 這些實現，最近騰訊也開源了Spring Cloud Tencent（暫時還沒有進入Spring Cloud 官方社群）。

2.1 Spring Cloud Alibaba

Spring Cloud Alibaba（後面簡稱SCA） 是目前國內Spring Cloud最活躍、元件最多，也是最容易替代 Spring Cloud Netflix 的實現。

下面張圖對相關功能和元件的對映關係表達得比較清晰了。

 

(來源：
https://www.oschina.net/question/4489239_2321891)

我們可以看到，SCA對Spring Cloud的實現，採用了幾個目前非常熱門的專案，基本上可以做到快速接入，穩定使用。

 

不過這裡有個地方需要注意，從SCA 的2.2.7-RELEASE版本後，不再支援dubbo的快速接入了，而是直接使用了Spring Cloud的原生呼叫方式（OpenFeign和RestTemplate）。

為什麼呢？查了下issue找到了社群相關討論
https://github.com/alibaba/spring-cloud-alibaba/issues/2398。

總結起來有幾點原因：

  • SCA的Spring Cloud Dubbo這個模組存在一些問題，且沒有人力繼續維護了，考慮到用的人不多，所以就不再繼續維護。
  • SCA的目的是為了將阿里雲相關元件能快速替換SpringCloud相關模組而誕生的，比如nacos、sentinal、seata、rocketMQ。
  • Dubbo自身生態非常成熟，一般不需要跟Spring Cloud混用，一般是二選一。尤其是Dubbo 3.x後支援了Mesh，通過rest方式呼叫完全可以自成體系。

2.2 Spring Cloud Tencent

Spring Cloud Tencent（後面簡稱SCT）是騰訊最近開源的SC實現框架，專案地址
https://github.com/Tencent/spring-cloud-tencent。

 

這是一整套自研的元件，以騰訊雲polaris為核心，實現 註冊中心、設定中心、服務路由、限流 等等。

目前相對來說騰訊集團內部使用較多，外界案例較少。

2.3 小結

Spring Cloud Netflix雖然不再維護，但是Spring Cloud依然火熱，SCA目前看可能會成為國內最佳實現選擇。

3、Spring Cloud與雲原生

3.1 特性差異

首先，Spring Cloud認為自己還是比較符合雲原生的

from https://github.com/spring-cloud/spring-cloud-commons：

Cloud Native is a style of application development that encourages easy adoption of best practices in the areas of continuous delivery and value-driven development. A related discipline is that of building 12-factor Applications, in which development practices are aligned with delivery and operations goals — for instance, by using declarative programming and management and monitoring. Spring Cloud facilitates these styles of development in a number of specific ways. The starting point is a set of features to which all components in a distributed system need easy access.

但是Spring Cloud 和目前最火熱的雲原生Service Mesh體系還是有非常大的差異。

可以從以下四個方面的對比

 

（表格來源：
https://medium.com/codex/a-spring-cloud-compatible-service-mesh-6ce58c571012）

前面談到了，Spring Cloud體系實際上是定義了一套程式設計模型（規範），包括服務註冊發現、負載均衡、熔斷降級等等。

但是這裡有些內容是否可以應用無關，下沉到基礎設施中？

在雲原生環境下，是可以的。

也就是Spring Cloud定義的部分規範，其實在雲原生環境下可能略顯冗餘了，Service Mesh可以做到應用無關。

當然，Spring Cloud能做到Service Mesh做不到的一些事情，比如 介面級別的治理、更細粒度的鏈路追蹤 等等。

另外，跨語言也是Service Mesh的一大殺器。

雲原生環境下，容器化執行，多雲部署，使得微服務不在關注到底是什麼技術棧，python、c++、Nodejs都可以非常容易在雲原生環境下執行。

但是Spring Cloud只適合java生態，並且侵入到java應用程式程式碼中，對於多語言是比較無力的。（其實這裡也是 容器化 後，對java語言統治力的一種衝擊）

3.2 成熟度

從成熟度來說，Service Mesh的istio + envoy的組合目前已經不少大中廠的實踐案例，但是跟Spring Cloud比起來，還是差不少。

2022 年 9 月 24 日，由雲原生社群主辦的第一屆 Service Mesh Summit 在上海成功舉辦，從大會內容上，我們可以看到，Service Mesh在 易用性、通用性、學習成本上，都還是比較高的。

市場在關注服務網格時更加得理性，而服務網格本身也更加「務實」，以實現快速平穩落地為出發點，解決落地過程中的各種問題，比如效能、資源佔用、跨叢集、多協定支援、功能擴充套件等等。解決這些問題，或者堅持在 Istio/Envoy 體系上繼續優化；或者轉投其他的實現，更換資料面代理，如 MOSN、Pipy、APISIX、Linkerd Proxy；再或者引入其他的技術來解決，如 eBPF、WASM、RDMA、DPDK 等等。

4、路在何方

4.1 只把k8s作為容器編排排程?

目前java為主的微服務體系還是比較完整的，所以即使使用了k8s，也可以僅僅把k8s用作容器編排，不需要對接istio的服務治理能力。

Spring Cloud全家桶肯定能滿足java體系下的微服務一站式設計與實現，這點毋庸置疑。

當然，問題主要還是在雲原生下，多語言的治理能力會有所缺失。

另外，流量管理上，和knative、seldon等平臺打通會比較麻煩，它們都是直接對接istio進行流量管理的。

4.2 Spring Cloud 的路？

Mesh體系下，由於天然支援HTTP呼叫，因此Spring Cloud的呼叫接入還是比較方便的，也有Spring Cloud Kubernetes專案做了註冊中心的打通。

核心的痛點在於對統一控制面的服務治理的接入。

對於Spring Cloud來說，就是要實現Proxyless體系，但是目前官方社群沒有看到這方面的特別探索。

倒是Spring Cloud Alibaba的服務治理元件Sentinel有一些變化。

Sentinel 的歷史

  • 2012 年，Sentinel 誕生，主要功能為入口流量控制。
  • 2013-2017 年，Sentinel 在阿里巴巴集團內部迅速發展，成為基礎技術模組，覆蓋了所有的核心場景。Sentinel 也因此積累了大量的流量歸整場景以及生產實踐。
  • 2018 年，Sentinel 開源，並持續演進。
  • 2019 年，Sentinel 朝著多語言擴充套件的方向不斷探索，推出 C++ 原生版本，同時針對 Service Mesh 場景也推出了 Envoy 叢集流量控制支援，以解決 Service Mesh 架構下多語言限流的問題。
  • 2020 年，推出 Sentinel Go 版本，繼續朝著雲原生方向演進。
  • 2021 年，Sentinel 正在朝著 2.0 雲原生高可用決策中心元件進行演進；同時推出了 Sentinel Rust 原生版本。同時我們也在 Rust 社群進行了 Envoy WASM extension 及 eBPF extension 等場景探索。
  • 2022 年，Sentinel 品牌升級為流量治理，領域涵蓋流量路由/排程、流量染色、流控降級、過載保護/範例摘除等；同時社群將流量治理相關標準抽出到 OpenSergo 標準中，Sentinel 作為流量治理標準實現。

另外，Sentinel 社群正在將流量治理相關標準抽出到 OpenSergo 標準中，Sentinel 作為流量治理標準實現。有關 Sentinel 流控降級與容錯 spec 的最新進展，請參考 opensergo-specification。

 

但是sentinel重點還是關注容錯能力，路由能力是缺失的。

所以，只能繼續關注OpenSergo會怎麼補齊這塊能力了。

4.3 學習Dubbo 3.0，全面擁抱雲原生

與Spring Cloud體系一樣聞名的Dubbo體系，我們已經可以看到dubbo 3.x從 Mesh 到 Proxyless 對雲原生的全面擁抱。

不僅從服務註冊發現模型上做了徹底改變（介面級別變成了應用級別），也在治理能力上對接xds。

dubbo 3.1.0作為一個重要的里程碑已經正式釋出

 

也許跟隨 Dubbo的腳步，可能可以更穩步走向雲原生。

 

希望能夠拋磚引玉，提供一些啟發和思考。如果你有其他補充和建議，歡迎留言討論。

 

都看到最後了，原創不易，點個關注，點個贊吧～
文章持續更新，可以微信搜尋「阿丸筆記 」第一時間閱讀，回覆【筆記】獲取Canal、MySQL、HBase、JAVA實戰筆記，回覆【資料】獲取一線大廠面試資料。
知識碎片重新梳理，構建Java知識圖譜：github.com/saigu/JavaK…（歷史文章查閱非常方便）