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

一、起源

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

对于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微服务架构问题,一个是容器架构和语言无关,所有功能都是自己这个架构所自带的,只是为了解决架构的某些问题而产生的。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>