很多公司由于歷史原因，都會有自研的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的腳步，可能可以更穩步走向云原生。