详解 Spring Cloud 版本问题

（给ImportNew加星标，提高Java技能）

1、让人头疼的多版本号体系

由于历史原因，Spring Cloud 分为了 Alibaba 和 Netflix 两个体系。
想要了解原因以及整个 Spring Cloud 体系的来龙去脉的同学可以去看我的另一篇文章：
知道以上前情后，我们来看看 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 体系后迭代更新出来的版本：