SpringCloud与云原生
共 5382字，需浏览 11分钟
·
2022-10-27 19:09
很多公司由于历史原因，都会有自研的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的脚步，可能可以更稳步走向云原生。
往期热门笔记合集推荐：
原创：阿丸笔记（微信公众号：aone_note），欢迎 分享，转载请保留出处。
没有留言功能的悲伤，扫描下方二维码「加我」聊些有的没的吧～