腳本之家服務器常用軟件

快捷導航

SpringCloud邁向云原生的步驟

更新時間：2022年10月27日 14:22:43 作者：阿丸

這篇文章主要介紹了SpringCloud怎么邁向云原生，通過本文我們來梳理一下Spring?Cloud的前世今生，以及未來云原生發(fā)展的趨勢，可以給這些RPC框架的演進帶來一些啟發(fā),感興趣的朋友跟隨小編一起看看吧

1、Spring Cloud的歷史

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

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

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

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

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

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

由于Netflix在開源投入上的策略調(diào)整，Eureka、Hystrix、Ribbon 相繼宣布停止維護，社區(qū)上人心惶惶，因為當時絕大部分開發(fā)者認為 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)。

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

(來源：
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ū)相關討論
https://github.com/alibaba/spring-cloud-alibaba/issues/2398。

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

SCA的Spring Cloud Dubbo這個模塊存在一些問題，且沒有人力繼續(xù)維護了，考慮到用的人不多，所以就不再繼續(xù)維護。
SCA的目的是為了將阿里云相關組件能快速替換SpringCloud相關模塊而誕生的，比如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) 注冊中心、配置中心、服務路由、限流等等。

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

2.3 小結(jié)

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

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

但是這里有些內(nèi)容是否可以應用無關，下沉到基礎設施中？

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

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

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

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

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

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

3.2 成熟度

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

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

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

4、路在何方

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

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

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

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

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

4.2 Spring Cloud 的路？

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

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

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

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

Sentinel 的歷史

2012 年，Sentinel 誕生，主要功能為入口流量控制。
2013-2017 年，Sentinel 在阿里巴巴集團內(nèi)部迅速發(fā)展，成為基礎技術模塊，覆蓋了所有的核心場景。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 品牌升級為流量治理，領域涵蓋流量路由/調(diào)度、流量染色、流控降級、過載保護/實例摘除等；同時社區(qū)將流量治理相關標準抽出到 OpenSergo 標準中，Sentinel 作為流量治理標準實現(xiàn)。

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