谈谈我理解的SpringCloud和Kubernetes的区别

• B站：https://www.bilibili.com/video/BV1R24y1u7a2

• 小道仙学习文档： https://d9bp4nr5ye.feishu.cn/wiki/wikcnkGEgfYwJspeNdXMegfQjQh

一、起源

为什么想写这篇文章呢？起源于我最开始对于它俩的误解，在很长一段时间我都分不清它们的区别。

对于SpringCloud在实际项目中并未使用过，只是自学过SpringCloud和SpringCloud Alibaba，也基于学习搭建过demo。

对于Kubernetes，目前这家公司就是使用的这个，但也只是管中窥豹，目前对于二者的关系，以及一些优缺点，还是有点认识的。

基于学习、总结的想法，然后就出了这篇文章，下面以对比的方式来介绍它们俩。

二、框架图

这个是我21年学习cloud画的流程图

这是基于我理解的K8S画的图

三、功能对比

下面这个问题的回答来自 chatGPD

SpringCloud 和 Kubernetes的区别

Spring Cloud 和 Kubernetes 都是用于构建和管理云原生应用程序的工具，但它们有一些重要的区别。
Spring Cloud 是一组用于构建微服务架构的框架和库。它提供了一系列解决方案，如服务注册、配置管理、负载均衡、断路器、路由和追踪等功能。Spring Cloud 建立在 Spring Framework 的基础上，它的目标是让开发人员能够更轻松地构建和管理微服务架构。Spring Cloud 可以运行在任何基础设施上，包括本地服务器、虚拟机和云环境。
Kubernetes 是一个容器编排平台，它允许用户自动化部署、扩展和管理容器化应用程序。Kubernetes 提供了许多功能，如服务发现、负载均衡、自动伸缩、滚动更新、容器存储和自动恢复等。Kubernetes 的设计目标是支持大规模的容器集群，它可以在任何基础设施上运行，包括本地服务器、公有云和私有云环境。
因此，Spring Cloud 和 Kubernetes 的主要区别在于它们的设计目标和重点。Spring Cloud 主要关注构建微服务架构，提供了一系列解决方案，而 Kubernetes 主要关注容器编排，提供了一套自动化部署、扩展和管理容器化应用程序的功能。当构建和管理微服务架构时，可以使用 Spring Cloud，当部署和管理容器化应用程序时，可以使用 Kubernetes。

就我的使用体验来说，我觉得它们并不是对立的，不是说用了K8S就不可以使用SpringCloud，相反我觉得它们是可以相互补充的。

1、服务网关

网关简单来说就是一个大门，你想要去访问门后的东西，第一步就是跨过大门。

• Cloud里面的网关代表有zuul、Gateway等，它们需要去连接一个注册中心，去注册中心拿到服务相关的信息，再去做相对的转发策略。
• K8S的网关是 ingress，目前我们的服务是部署在阿里云上面的，使用的是 nginx ingress controller，本质上是基于nginx + luajit 来实现的，借助luajit框架可以让我们像编程一样的去操作nginx能力。（可以去看看开源框架 OpenResty）

以我的使用体验来看，我更喜欢 ingress，它依托k8s本身，新增服务的时候会自动的去发现服务，我们的服务本身没有任何的依赖，比如配置注册中心地址什么的，部署即刻生效。

2、服务注册/发现

• Cloud的服务注册发现，是需要借助其它中间件比如Eureka、Nacos等，这些组件也还需要借助第三方的存储比如MySQL。
• K8S的数据存储是ETCD，理所当然服务信息也会存储到这个里面，自然就形成了注册，ingress会从etcd里面获取信息，就形成了服务的发现，完全是K8S自带的。

3、服务调用

不管是cloud还是k8s，其实服务本身的通信是没有什么限制的，比如你可以使用HTTP，也可以用 RPC。

相对于cloud，k8s服务调用更有优势，你注册了一个服务，会生成一个服务内部调用地址，通过这个地址去调用服务走内部通信，一个是快，一个是自带负载均衡。

如果你想使用RPC调用，在K8S里面也是完全可以的，我们的服务就在慢慢的开始使用OpenFegin，目的是为了统一技术站，为后续服务治理做准备。

4、服务配置

• Cloud 里面的配置中心有config、nacos等，可以做到热更新，也可以做到不同的环境不同的配置。
• K8S里面可以使用configMap，它就是一个 key-value 格式的数据，我们的value可以是任何格式的数据，这取决于我们的服务想用什么比如 Java里面的 yaml，nginx里面的conf。

从功能来看nacos是全胜的，但是从业务场景来看，有时候configMap更适合我们

1. 热更新：nacos是支持热更新的，configMap不支持，不过K8S的pod支持滚动升级，偶尔的一次修改配置文件也可以做到用户无感知，只是操作稍微麻烦些，需要重启。
2. 编写体验：nacos有很好的编辑器，不同的文件会有不同的高亮显示，但是阿里云的configMap目前只是一个单纯的文本框。（这点我也无所谓，一般我都是复制出来的本地编辑再复制回去）
3. 难易度：毫无疑问configMap属于K8S本身肯定要简单很多不需要单独的服务并且代码无任何侵入。

5、服务熔断、降级

K8S和Cloud一样需要引入第三方中间件，如 sentinel和hystrix

6、分布式事务

同上，也需要引入第三方中间件，或自己做补偿机制

四、总结

个人觉得它们最大的区别在于一个是为了解决Java微服务架构问题，一个是容器架构和语言无关，所有功能都是自己这个架构所自带的，只是为了解决架构的某些问题而产生的。