总述
在平时我们构建微服务的过程中需要做如 服务发现注册 、配置中心 、消息总线 、负载均衡 、断路器 、数据监控 等操作，而 Spring Cloud 为我们提供了一套简易的编程模型，使我们能在 Spring Boot 的基础上轻松地实现微服务项目的构建
版本
版本号均为英国伦敦地铁站的站名
1 | Angel、Brixton、Camden、Dalston、Edgware、Finchley、Greenwich、Hoxton |
框架
1. 服务发现框架-Eureka
可以充当服务发现的组件有很多：
Zookeeper，Consul，Eureka等。Eureka是基于REST（代表性状态转移）的服务，主要在AWS云中用于定位服务，以实现负载均衡和中间层服务器的故障转移。我们称此服务为Eureka服务器。Eureka还带有一个基于Java的客户端组件Eureka Client，它使与服务的交互变得更加容易。客户端还具有一个内置的负载平衡器，可以执行基本的循环负载平衡。在Netflix，更复杂的负载均衡器将Eureka包装起来，以基于流量，资源使用，错误条件等多种因素提供加权负载均衡，以提供出色的弹性。注册、续约等，底层都是使用的RestTemplate
1.1. 服务注册 Register
当 Eureka 客户端向 Eureka Server 注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等
1.2. 服务续约 Renew
Eureka 客户会每隔30秒(默认情况下)发送一次心跳来续约。通过续约来告知 Eureka Server 该 Eureka 客户仍然存在，没有出现问题。正常情况下，如果 Eureka Server 在90秒没有收到 Eureka 客户的续约，它会将实例从其注册表中删除。
1.3. 获取注册列表信息 Fetch Registries
Eureka 客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与 Eureka 客户端的缓存信息不同, Eureka 客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka 客户端则会重新获取整个注册表信息。Eureka 服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka 客户端和 Eureka 服务器可以使用JSON/XML 格式进行通讯。在默认的情况下 Eureka 客户端使用压缩 JSON 格式来获取注册列表的信息。
1.4. 服务下线 Cancel
Eureka 客户端在程序关闭时向Eureka服务器发送取消请求。发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：DiscoveryManager.getInstance().shutdownComponent();
1.5. 服务剔除 Eviction
在默认的情况下，当 Eureka 客户端连续90秒(3个续约周期)没有向 Eureka 服务器发送心跳，Eureka 服务器会将该服务实例从服务注册列表删除，即服务剔除。
2. 负载均衡-Ribbon
常用的负载均衡组件有
Nginx，Ribbon等。Nginx是一种集中式的负载均衡器，将所有请求都集中起来，然后再进行负载均衡。在Nginx中请求是先进入负载均衡器，而在Ribbon中是先在客户端进行负载均衡才进行请求的，其是一个客户端/进程内负载均衡器，运行在消费者端
2.1. 负载均衡算法
- RoundRobinRule：轮询策略。Ribbon 默认采用的策略。若经过一轮轮询没有找到可用的 provider，其最多轮询 10 轮。若最终还没有找到，则返回 null
- RandomRule: 随机策略，从所有可用的 provider 中随机选择一个
- RetryRule: 重试策略。先按照 RoundRobinRule 策略获取 provider，若获取失败，则在指定的时限内重试。默认的时限为 500 毫秒
- 自定义：需要实现
IRule接口，然后修改配置文件或者自定义Java Config类
3. 服务调用映射-Open Feign
OpenFeign也是运行在消费者端的，使用Ribbon进行负载均衡，所以OpenFeign直接内置了Ribbon。
4. 服务降级熔断器-Hystrix
在分布式环境中，不可避免地会有许多服务依赖项中的某些失败。
Hystrix是一个库，可通过添加等待时间容限和容错逻辑来帮助您控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点，停止服务之间的级联故障并提供后备选项来实现此目的，所有这些都可以提高系统的整体弹性。
4.1. 服务雪崩
服务A调用了服务B，服务B再调用了服务C，但是因为某些原因，服务C顶不住了，这个时候大量请求会在服务C阻塞，进而导致服务B和服务A也无法正常使用，这就叫服务雪崩
4.2. 熔断
熔断就是服务雪崩的一种有效解决方案。当指定时间窗内的请求失败率达到设定阈值时，系统将通过断路器 直接将此请求链路断开。也就是上面服务B调用服务C在指定时间窗内，调用的失败率到达了一定的值，那么
Hystrix则会自动将 服务B与C 之间的请求都断了，以免导致服务雪崩现象
4.3. 降级
降级是为了更好的用户体验，当一个方法调用异常时，通过执行另一种代码逻辑来给用户友好的回复。这也就对应着
Hystrix的 后备处理模式，比如这个时候有一个热点新闻出现了，我们会推荐给用户查看详情，然后用户会通过id去查询新闻的详情，但是因为这条新闻太火了，大量用户同时访问可能会导致系统崩溃，那么我们就进行服务降级，一些请求会做一些降级处理比如当前人数太多请稍后查看等等
5. 微服务网关-Zuul
Zuul是为了实现动态路由、监视、弹性和安全性而构建的，用于对请求进行鉴权、限流、 路由、监控等功能。Zuul是消费者工程调用入口
6. 配置管理-Config
配置管理的框架有
Spring Cloud Config，disconf，Apollo等等。Spring Cloud Config为分布式系统中的外部化配置提供服务器和客户端支持。使用Config服务器，可以在中心位置管理所有环境中应用程序的外部属性，既能对配置文件统一地进行管理，又能在项目运行时动态修改配置文件。其将各个应用/系统/模块的配置文件存放到统一的地方然后进行管理(Git 或者 SVN)。一般我们会使用Bus消息总线 +Spring Cloud Config进行配置的动态刷新
7. 消息总线-Bus
用于将服务和服务实例与分布式消息系统链接在一起的事件总线。在集群中传播状态更改很有用（例如配置更改事件），作用是管理和广播分布式系统中的消息，也就是消息引擎系统中的广播模式
