SpringCloud是什么？
SpringCloud是基于SpringBoot提供了一套微服务解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。
SpringCloud利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等，它们都可以用SpringBoot的开发风格做到一键启动和部署。
SpringBoot并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
简单理解
SpringCloud是分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，微服务全家桶。
SpringCloud和SpringBoot的关系
SpringBoot专注于快速方便的开发单个个体微服务。
SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务。
简单理解
SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot，属于依赖的关系。
SpringCloud和Dubbo的比较
SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。严格来说，这两种方式各有优劣。虽然从一定程度上来说，SpringCloud牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。最为重要的是，DUBBO停止了5年左右的更新，虽然2017.7重启了，对于技术发展的新需求，需要由开发者自行拓展升级（比如当当网弄出了DubboX），这对于很多想要采用微服务架构的中小软件组织，显然是不太合适的，中小公司没有这么强大的技术能力去修改Dubbo源码和周边的一整套解决方案，并不是每一个公司都有阿里的大牛和真实的线上生产环境测试过。
简单理解
如果你去买电脑，SpringCloud就好比品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性。而Dubbo就好比组装机，各个组件的选择度很高，而且依赖于第三方的组件，好像总让人不太放心。
SpringCloud能做什么？
- 服务注册与发现：Eureka
- 负载均衡：Ribbon、Feign
- 断路器：Hystrix
- 监控：Hystrix Dashboard
- 路由网关：Zuul
- 分布式配置中心：SpringCloud Config
- 消息总线：SpringCloud Bus
- 服务链路追踪：SpringCloud Sleuth
- ......
Spring Cloud版本
大版本
版本号规则
Spring Cloud并没有熟悉的数字版本号，而是对应一个开发代号。
Cloud代号 | Boot版本(train) | Boot版本(tested) | lifecycle |
Angle | 1.2.x | incompatible with 1.3 | EOL in July 2017 |
Brixton | 1.3.x | 1.4.x | 2017-07卒 |
Camden | 1.4.x | 1.5.x | - |
Dalston | 1.5.x | not expected 2.x | - |
Edgware | 1.5.x | not expected 2.x | - |
Finchley | 2.x | not expected 1.5.x | - |
开发代号看似没有什么规律，但实际上首字母是有顺序的，比如：Dalston版本，我们可以简称 D 版本，对应的 Edgware 版本我们可以简称 E 版本。
D版本和E版本的区别
二者均基于SpringBoot的1.5.x版本。但支持其他组件的版本不同，如以 Dalston.SR4 和 Edgware.RELEASE 来对比：
spring-cloud-config 分别对应 1.3.3和 1.4.0;
spring-cloud-netflix 分别对应 1.3.5和 1.4.0;
spring-cloud-consul 分别对应 1.2.1和 1.3.0;
spring-cloud-gateway 前者不支持，后者 1.0.0。
每个小版本的不同，会有细微差别。
F版本
F版本是个绝对的大版本，几乎所有组件，全部同步变更版本号为2.x。
小版本
Spring Cloud 小版本分为:
SNAPSHOT： 快照版本，随时可能修改
M： MileStone，M1表示第1个里程碑版本，一般同时标注PRE，表示预览版版。
SR： Service Release，SR1表示第1个正式版本，一般同时标注GA：(GenerallyAvailable),表示稳定版本。
选择版本
大版本
- 首先说明，各个版本之间组件变化不大，但细节略有不同，比如配置项名称、或者新版本增加新的配置方式。
从这一点来看，选择哪个版本都不是大问题，但提醒一下，遇到坑时，最好根据版本进行查询，否则你会发现你找到的办法不行。实际上是版本不匹配。
- 如果你项目需要和其他老项目交叉，以兼容为第一要务。
- 如果全新项目，可以考虑较新版本，如E版。如果你爱好踩坑，F拿去。
小版本
小版本没啥可说的，尝鲜：SNAPSHOT，生产：GA。
Spring Cloud与Spring Boot版本匹配关系
在这篇文章中：
- Spring Cloud版本
- Spring Cloud与Spring Boot版本匹配关系
Spring Cloud版本
在写本篇文章时，Spring Cloud版本演进情况如下：
版本名称 | 版本 |
Finchley | snapshot版 |
Edgware | snapshot版 |
Dalston SR1 | 当前最新稳定版本 |
Camden SR7 | 稳定版本 |
Brixton SR7 | 稳定版本 |
Angel SR6 | 稳定版本 |
从下Angel到上Finchley可以看出，版本的第一个字母是按照A－Z顺序编排的。这些单词是什么含义呢，大概的搜一下可以得出基本都是地名，官方说明是这些版本号的单词来自于英国伦敦的地铁站站名。
那么为什么要用单词而不是数字类型的版本号呢？ 因为Spring Cloud包含了一系列的子系统，Spring Cloud Config，Spring Cloud Netflix，Spring Cloud Bus等，为了防止与这些子系统的版本号混淆，Spring Cloud的版本号全部使用英文单词。
版本号后面的SRX，X代表一个数字，这个是小版本号，就是在特定的版本中，修复一些致命问题，做的升级版本号。
Spring Cloud与Spring Boot版本匹配关系
Spring Cloud | Spring Boot |
Finchley | 兼容Spring Boot 2.0.x，不兼容Spring Boot 1.5.x |
Dalston和Edgware | 兼容Spring Boot 1.5.x，不兼容Spring Boot 2.0.x |
Camden | 兼容Spring Boot 1.4.x，也兼容Spring Boot 1.5.x |
Brixton | 兼容Spring Boot 1.3.x，也兼容Spring Boot 1.4.x |
Angel | 兼容Spring Boot 1.2.x |
