SpringCloud 简介及五大常用组件介绍
SpringCloud 是微服务架构的集大成者，将一系列优秀的组件进行了整合。基于springboot构建，对我们熟悉spring的程序员来说，上手比较容易。
通过一些简单的注解，我们就可以快速的在应用中配置一下常用模块并构建庞大的分布式系统。
SpringCloud的组件相当繁杂，拥有诸多子项目。重点关注Netflix
-
SpringCloud 的版本说明
：springcloud项目是由多个独立项目集合而成的，每个项目都是独立的，各自进行自己的迭代和版本发布。所以springcloud不方便使用版本号来管理，而是使用版本名。以避免和子项目版本号的冲突。
版本名的来源是伦敦的地铁站名，以字母排序。比如最早的Release版本为Angel，第二个Release版本为Brixton。。。
当一个版本的update积累的比较多或者解决了一个严重bug时，会发布一个ServiceRelease版本，简称SR，后面带的数字就是该大版本下的第一次发布。
从官网上看，springcloud的F版本是基于springboot的2.0.x构建，之前的是基于springboot的1.5.x构建 -
下面只简单介绍下经常用的5大组件
- 服务发现——Netflix Eureka
- 客服端负载均衡——Netflix Ribbon
- 断路器——Netflix Hystrix
- 服务网关——Netflix Zuul
- 分布式配置——Spring Cloud Config
-
Eureka(注册发现)
作用：实现服务治理（服务注册与发现）
简介：Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。
由两个组件组成：Eureka服务端和Eureka客户端。
Eureka服务端用作服务注册中心。支持集群部署。
Eureka客户端是一个java客户端，用来处理服务注册与发现。
在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。 -
Ribbon
作用：Ribbon，主要提供客户侧的软件负载均衡算法。
简介：Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。
PS:注意看上图，关键点就是将外界的rest调用，根据负载均衡策略转换为微服务调用。Ribbon有比较多的负载均衡策略，以后专门讲解。
-
Hystrix
作用：断路器，保护系统，控制故障范围。
简介：为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。 -
Zuul
作用：api网关，路由，负载均衡等多种作用
简介：类似nginx，反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。
在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。 -
Config
作用：配置管理
简介：SpringCloud Config提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。
这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。
以下为SpringCloud config 动态配置更新实现方式及原理
1、ConfigServer(配置中心服务端)从远端git拉取配置文件并在本地git一份，ConfigClient（微服务）从ConfigServer端获取自己对应 配置文件；
2、当远端git仓库配置文件发生改变，ConfigServer如何通知到ConfigClient端，即ConfigClient如何感知到配置发生更新？
Spring Cloud Bus会向外提供一个http接口，即图中的/bus/refresh。我们将这个接口配置到远程的git的webhook上，当git上的文件内容发生变动时，就会自动调用/bus-refresh接口。Bus就会通知config-server，config-server会发布更新消息到消息总线的消息队列中，其他服务订阅到该消息就会信息刷新，从而实现整个微服务进行自动刷新。
- 提交配置触发post调用客户端A的bus/refresh接口
- 客户端A接收到请求从Server端更新配置并且发送给Spring Cloud Bus总线
- Spring Cloud bus接到消息并通知给其它连接在总线上的客户端，所有总线上的客户端均能收到消息
- 其它客户端接收到通知，请求Server端获取最新配置
- 全部客户端均获取到最新的配置
存在问题：
- 打破了微服务的职责单一性。微服务本身是业务模块，它本不应该承担配置刷新的职责。
- 破坏了微服务各节点的对等性。
- 有一定的局限性。WebHook的配置随着承担刷新配置的微服务节点发生改变。
改进如下方式二：配置中心Server端承担起配置刷新的职责，原理图如下
- 提交配置触发post请求给server端的bus/refresh接口
- server端接收到请求并发送给Spring Cloud Bus总线
- Spring Cloud bus接到消息并通知给其它连接到总线的客户端
- 其它客户端接收到通知，请求Server端获取最新配置
- 全部客户端均获取到最新的配置