目录
1.让人头疼的多版本号体系
2.目录关系
3.为什么会有多个版本号体系
1.让人头疼的多版本号体系
由于历史原因,spring cloud分为了Alibaba和Netflix两个体系。
想要了解原因以及整个spring cloud体系的来龙去脉的同学可以去看我的另一篇文章:
SpringCloud概论__BugMan的博客-CSDN博客
知道以上前情后,我们来看看spring cloud的版本号有多乱:
打开官网首先有个总项目的版本列表:
然后往下翻是,Netflix的spring cloud和spring boot各版本之间的适配关系:
也就是说Netflix的版本号应该是列表中那样的。
但是我们点进Netflix的项目会发现它的版本号列表是这样的:
ok,这个时候才开始入门的小伙伴就蒙蔽了,会有以下几个疑惑:
- 既然是分成了Alibaba和Netflix两个体系,为什么spring cloud这个总项目列表还会有个版本号
- spring boot适配的适配列表中显示的Netflix的版本号列表为什么会和点进Netflix中看见的版本号列表不一样,为什么会有两套Netflix的版本号?
- 我要用spring cloud的时候到底该用哪一个的maven坐标?
本文会先从组件关系讲起,理清楚spring cloud的项目目录结构,然后再顺着理清楚版本号问题。
2.目录关系
首先我们需要理清楚整个spring cloud生态圈里组件之间的关系,也就是官网的目录为什么是那个样子。
要实现微服务,最核心的问题是:
- 服务注册和发现
- 容错
Netflix和Alibaba两个体系对以上两点给出了自己不同的实现,总的来说就是各自推出了不同的注册中心组件和容错组件。除此之外在易能力扩展上,都是通集成接入第三方组件来实现的,如网关、总线、配置中心。
有了这个认识我们再来看整个spring cloud的项目列表就不会这么晕了。
我们进入spring官网,可以看到Alibaba和Netflix两个子项目,和与他们同级的很多子项目,Alibaba和Netflix的项目下包含了自己的注册中心组件和容错组件,和Alibaba、Netflix同级的,是一些扩展的三方组件如gateway(网关)、config(配置中心)、bus(总线)等。
3.为什么会有多个版本号体系
其实组件关系理清楚后,版本号的问题就很好明白了了。虽然由于历史原因,spring cloud分成了Alibaba和Netflix两派,但spring cloud是Netflix先做出来的,所以官网上还是以Netflix为中心来对整个spring cloud进行描述的。真正的Netflix自己推出的全家桶的版本其实就是适配列表里列出来的那些版本:
我们随便点进一个版本的Netflix的全家桶,可以看到其实就是注册中心(Spring Cloud Neflix)+其它组件:
后面Netflix的spring cloud的核心研发人员离职后,公司就将自己的spring cloud贡献给了spring cloud官方社区,由官方社区来对Netflix体系的spring cloud进行迭代。所以总项目上的版本号列表是spring cloud官方社区接收Netflix体系后迭代更新出来的版本:
随便点进去一个版本,可以看到其实也是围绕Netflix给出的一个全家桶:
然后官网上spring cloud Netflix这个子项目就只单纯的维护eureka版本:
我们点进随便一个版本,可以看到,就是很单纯的eureka:
至于spring cloud Alibaba,就很与世无争,就单纯的维护好自己的版本号:
维护好自己的nacos和sentinel:文章来源:https://www.toymoban.com/news/detail-474560.html
文章来源地址https://www.toymoban.com/news/detail-474560.html
到了这里,关于详解Spring Cloud版本问题的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!