目录
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：
