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

尤其是在2015-2017期間，Spring Cloud剛剛面世，Dubbo停止維護多年，很多公司在設(shè)計自己的RPC框架時，都會基于Spring Cloud做二次開發(fā)。并且會大量使用Spring Cloud Netflix相關(guān)的模塊與代碼。

因此，我們?nèi)ナ崂硪幌耂pring Cloud的前世今生，以及未來云原生發(fā)展的趨勢，可以給這些RPC框架的演進帶來一些啟發(fā)。

1、Spring Cloud的歷史

Spring Cloud 自 2015 年 3 月推出之后，很快就在 Java 微服務(wù)生態(tài)中，成為開發(fā)人員的首選技術(shù)棧。

Spring Cloud 在 Spring Boot 的基礎(chǔ)上，保留 Java 開發(fā)習(xí)慣，加入分布式特性，提供了一系列通用工具來幫助開發(fā)者在分布式系統(tǒng)里快速構(gòu)建一些常見模式，現(xiàn)在已成為使用范圍最廣的微服務(wù)架構(gòu)之一。

Spring Cloud提供了微服務(wù)開發(fā)所需的配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、集群狀態(tài)管理等組件。最重要的是，跟Spring Boot框架一起使用的話，會讓你開發(fā)微服務(wù)架構(gòu)非常方便。

Spring Cloud本身不是新的框架，它是一系列框架的有機組合，利用Spring Boot的開發(fā)便利性巧妙地簡化了分布式系統(tǒng)基礎(chǔ)設(shè)施的開發(fā)。

注意，并非所有組件都由Spring提供，Netflix扮演了重要的角色。注冊中心Eureka、熔斷器Hystrix、負載均衡組件Ribbon、網(wǎng)關(guān)Zuul等重要組件均由Netflix提供，主要貢獻來自 Netflix OSS。

2、Spring Cloud的現(xiàn)在

由于Netflix在開源投入上的策略調(diào)整，Eureka、Hystrix、Ribbon 相繼宣布停止維護，社區(qū)上人心惶惶，因為當(dāng)時絕大部分開發(fā)者認(rèn)為 Spring Cloud = Spring Cloud Netflix。

但實際上 Spring Cloud 是一套規(guī)范，這套規(guī)范并不是只有 Netflix OSS，還有 Spring Cloud Alibaba，Spring Cloud Zookeeper，Spring Cloud Consul，Spring Cloud Kubernetes 這些實現(xiàn)，最近騰訊也開源了Spring Cloud Tencent（暫時還沒有進入Spring Cloud 官方社區(qū)）。

2.1 Spring Cloud Alibaba

Spring Cloud Alibaba（后面簡稱SCA） 是目前國內(nèi)Spring Cloud最活躍、組件最多，也是最容易替代 Spring Cloud Netflix 的實現(xiàn)。

下面張圖對相關(guān)功能和組件的映射關(guān)系表達得比較清晰了。

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

我們可以看到，SCA對Spring Cloud的實現(xiàn)，采用了幾個目前非常熱門的項目，基本上可以做到快速接入，穩(wěn)定使用。

不過這里有個地方需要注意，從SCA 的2.2.7-RELEASE版本后，不再支持dubbo的快速接入了，而是直接使用了Spring Cloud的原生調(diào)用方式（OpenFeign和RestTemplate）。

為什么呢？查了下issue找到了社區(qū)相關(guān)討論https://github.com/alibaba/spring-cloud-alibaba/issues/2398。

總結(jié)起來有幾點原因：

SCA的Spring Cloud Dubbo這個模塊存在一些問題，且沒有人力繼續(xù)維護了，考慮到用的人不多，所以就不再繼續(xù)維護。

SCA的目的是為了將阿里云相關(guān)組件能快速替換SpringCloud相關(guān)模塊而誕生的，比如nacos、sentinal、seata、rocketMQ。

Dubbo自身生態(tài)非常成熟，一般不需要跟Spring Cloud混用，一般是二選一。尤其是Dubbo 3.x后支持了Mesh，通過rest方式調(diào)用完全可以自成體系。

2.2 Spring Cloud Tencent

Spring Cloud Tencent（后面簡稱SCT）是騰訊最近開源的SC實現(xiàn)框架，項目地址https://github.com/Tencent/spring-cloud-tencent。

這是一整套自研的組件，以騰訊云polaris為核心，實現(xiàn) 注冊中心、配置中心、服務(wù)路由、限流 等等。

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

2.3 小結(jié)

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

3、Spring Cloud與云原生

3.1 特性差異

首先，Spring Cloud認(rèn)為自己還是比較符合云原生的

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體系實際上是定義了一套編程模型（規(guī)范），包括服務(wù)注冊發(fā)現(xiàn)、負載均衡、熔斷降級等等。

但是這里有些內(nèi)容是否可以應(yīng)用無關(guān)，下沉到基礎(chǔ)設(shè)施中？

在云原生環(huán)境下，是可以的。

也就是Spring Cloud定義的部分規(guī)范，其實在云原生環(huán)境下可能略顯冗余了，Service Mesh可以做到應(yīng)用無關(guān)。

當(dāng)然，Spring Cloud能做到Service Mesh做不到的一些事情，比如 接口級別的治理、更細粒度的鏈路追蹤 等等。

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

云原生環(huán)境下，容器化運行，多云部署，使得微服務(wù)不再關(guān)注到底是什么技術(shù)棧，python、c++、Nodejs都可以非常容易在云原生環(huán)境下運行。

但是Spring Cloud只適合java生態(tài)，并且侵入到j(luò)ava應(yīng)用程序代碼中，對于多語言是比較無力的。（其實這里也是 容器化 后，對java語言統(tǒng)治力的一種沖擊）

3.2 成熟度差異

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

2022 年 9 月 24 日，由云原生社區(qū)主辦的第一屆 Service Mesh Summit 在上海成功舉辦，從大會內(nèi)容上，我們可以看到，Service Mesh在 易用性、通用性、學(xué)習(xí)成本上，都還是比較高的。

市場在關(guān)注服務(wù)網(wǎng)格時更加得理性，而服務(wù)網(wǎng)格本身也更加“務(wù)實”，以實現(xiàn)快速平穩(wěn)落地為出發(fā)點，解決落地過程中的各種問題，比如性能、資源占用、跨集群、多協(xié)議支持、功能擴展等等。解決這些問題，或者堅持在 Istio/Envoy 體系上繼續(xù)優(yōu)化；或者轉(zhuǎn)投其他的實現(xiàn)，更換數(shù)據(jù)面代理，如 MOSN、Pipy、APISIX、Linkerd Proxy；再或者引入其他的技術(shù)來解決，如 eBPF、WASM、RDMA、DPDK 等等。

4、路在何方

4.1 只把k8s作為容器編排調(diào)度？

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

Spring Cloud全家桶肯定能滿足java體系下的微服務(wù)一站式設(shè)計與實現(xiàn)，這點毋庸置疑。

當(dāng)然，問題主要還是在云原生下，多語言的治理能力會有所缺失。

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

4.2 Spring Cloud 的路？

Mesh體系下，由于天然支持HTTP調(diào)用，因此Spring Cloud的調(diào)用接入還是比較方便的，也有Spring Cloud Kubernetes項目做了注冊中心的打通。

核心的痛點在于對統(tǒng)一控制面的服務(wù)治理的接入。

對于Spring Cloud來說，就是要實現(xiàn)Proxyless體系，但是目前官方社區(qū)沒有看到這方面的特別探索。

倒是Spring Cloud Alibaba的服務(wù)治理組件Sentinel有一些變化。

Sentinel 的歷史

• 2012 年，Sentinel 誕生，主要功能為入口流量控制。
• 2013-2017 年，Sentinel 在阿里巴巴集團內(nèi)部迅速發(fā)展，成為基礎(chǔ)技術(shù)模塊，覆蓋了所有的核心場景。Sentinel 也因此積累了大量的流量歸整場景以及生產(chǎn)實踐。
• 2018 年，Sentinel 開源，并持續(xù)演進。
• 2019 年，Sentinel 朝著多語言擴展的方向不斷探索，推出 C++ 原生版本，同時針對 Service Mesh 場景也推出了 Envoy 集群流量控制支持，以解決 Service Mesh 架構(gòu)下多語言限流的問題。
• 2020 年，推出 Sentinel Go 版本，繼續(xù)朝著云原生方向演進。
• 2021 年，Sentinel 正在朝著 2.0 云原生高可用決策中心組件進行演進；同時推出了 Sentinel Rust 原生版本。同時我們也在 Rust 社區(qū)進行了 Envoy WASM extension 及 eBPF extension 等場景探索。
• 2022 年，Sentinel 品牌升級為流量治理，領(lǐng)域涵蓋流量路由/調(diào)度、流量染色、流控降級、過載保護/實例摘除等；同時社區(qū)將流量治理相關(guān)標(biāo)準(zhǔn)抽出到 OpenSergo 標(biāo)準(zhǔn)中，Sentinel 作為流量治理標(biāo)準(zhǔn)實現(xiàn)。

另外，Sentinel 社區(qū)正在將流量治理相關(guān)標(biāo)準(zhǔn)抽出到 OpenSergo 標(biāo)準(zhǔn)中，Sentinel 作為流量治理標(biāo)準(zhǔn)實現(xiàn)。有關(guān) Sentinel 流控降級與容錯 spec 的最新進展，請參考 opensergo-specification。

但是sentinel重點還是關(guān)注容錯能力，路由能力是缺失的。

所以，只能繼續(xù)關(guān)注OpenSergo會怎么補齊這塊能力了。

4.3 學(xué)習(xí)Dubbo 3.0，全面擁抱云原生？

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

不僅從服務(wù)注冊發(fā)現(xiàn)模型上做了徹底改變（接口級別變成了應(yīng)用級別），也在治理能力上對接xds。

dubbo 3.1.0作為一個重要的里程碑已經(jīng)正式發(fā)布

也許跟隨 Dubbo的腳步，可能可以更穩(wěn)步走向云原生。