SpringCloud和Kubernetes的区别

又见小道仙:

https://blog.csdn.net/Tomwildboar/article/details/129531315

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

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

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

(其实也有点不了解两个的区别,感觉他们功能挺相似的)

springcloud的流程图

K8S的图(我对这个没啥研究,先记录,抽时间研究)

功能对比

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。

可以相互补充

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更适合我们

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

5、服务熔断、降级

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

6、分布式事务

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

总结

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

相关推荐
木与子不厌2 小时前
微服务自定义过滤器
运维·数据库·微服务
微扬嘴角2 小时前
springcloud篇1(微服务技术栈、服务拆分与远程调用、Eureka、Nacos)
spring cloud·微服务·eureka
time_silence2 小时前
微服务——技术选型与框架
微服务·架构
dbcat官方2 小时前
1.微服务灰度发布(方案设计)
java·数据库·分布式·微服务·中间件·架构
S-X-S3 小时前
【微服务】整合Nacos注册中心和动态配置
微服务·rpc·架构
小李不想输啦9 小时前
什么是微服务、微服务如何实现Eureka,网关是什么,nacos是什么
java·spring boot·微服务·eureka·架构
张铁铁是个小胖子9 小时前
微服务学习
java·学习·微服务
明明真系叻11 小时前
第二十六周机器学习笔记:PINN求正反解求PDE文献阅读——正问题
人工智能·笔记·深度学习·机器学习·1024程序员节
Light6014 小时前
云途领航:现代应用架构助力企业转型新篇
微服务·架构·saas·paas·iaas·ipaas·apaas
time_silence20 小时前
微服务——不熟与运维
运维·微服务·架构