Spring Cloud
是一个基于Spring Boot实现的微服务架构开发工具。它为微服务架构中涉及的配置管理、服务治理、断路器、只能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。
Spring Cloud的组件
Spring Cloud Config：配置管理工具，支持使用Git存储配置内容，可以使用它实现应用配置的外部化存储，并支持客户端配置信息刷新、加密/解密配置内容等。
Spring Cloud Netflix:核心组件，对多个Netflix OSS开源套件进行了整合。其中包括:
1.Eureka：服务治理组件，包含服务注册中心、服务注册与发现机制的实现。
2.Hystrix：容错管理组件，实现断路器模式，帮助服务依赖中出现的延迟和为故障提供强大的容错能力。
3.Ribbon:客户端负载均衡的服务调用组件。
4.Feign：基于Ribbon和Hystrix的声明式服务调用组件。
5.Zuul：网关组件，提供智能路由、访问过滤等功能。
6.Archaius:外部化配置组件。
Spring Cloud Bus:事件、消息总线，用于传播集群中的状态变化或事件，以及触发后续的处理，比如用来动态刷新配置等。
Spring Cloud Cluster:针对Zookeeper、Redis、Hazelcast、Consul的选举算法和通用状态模式的实现。
Spring Cloud Cloudfoundry:与Pivotal Cloudfoundry的整合支持。
Spring Cloud Consul:服务发现与配置工具。
Spring Cloud Stream:通过Redis、Rabbit或者Kafka实现的消费微服务，可以通过简单的声明式模型来发送和接受消息。
Spring Cloud AWS:用于简化整合亚马逊的 Web Service的组件
Spring Cloud Security:安全工具包，提供Zuul代理中OAuth2客户端请求的中继器。
Spring Cloud Sleuth:Spring CLoud应用的分布式跟踪实现，可以完美整合Zipkin
Spring Cloud Zookeeper：基于Zookeeper的服务发现与配置管理组件。
Spring Cloud Eureka:是Spring Cloud Netflix微服务套件中的一部分，它基于Netflix Eureka做了二次封装，主要负责完成微服务架构中的服务治理功能。
服务提供者
1.服务注册，服务提供者在启动的时候通过发送Rest请求的方式将自己注册到Eureka Server上，同时带上自身服务的一些元数据信息。Eureka Server接收到这个Rest请求后，将元数据信息存储在一个双层结构Map中，其中第一层的key是服务名，第二层的key是具体服务的实例名。
2.服务同步，由于两个注册中心进行了相互注册，当服务提供者发送注册请求到一个服务注册中心时，它会将该请求转发给集群中其他注册中心，从而实现注册中心之间的服务同步。
3.服务续约，在注册完服务后，服务提供者会维护一个心跳用来持续告诉Eureka Server:"我还活着"，以防止Eureka Server的“剔除任务”将该服务实例从服务列表中剔除。
服务消费者
1.获取服务，当我们启动服务消费者的时候，它会发送一个Rest请求给服务的注册中心，来获取上面注册的服务清单，为了性能考虑，Eureka Server会维护一份只读的服务清单来返回给客户端，同时该缓存清单会隔30秒更新一次。
2.服务调用，服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。客户端可以可以根据自己的需要决定具体调用哪个实例，在Ribbon中会默认采用轮询的方式进行调用，从而实现客户端的负载均衡。对于访问的选择，Eureka中有Region和Zone的概念，一个Region中可以包含多个Zone，每个服务客户端需要被注册到一个Zone中。
3.服务下线，在客户端程序中，当服务实例进行正常关闭操作时，它会触发一个服务下线的Rest请求给Eureka Server，告诉服务注册中心，“我要下线了”。服务端在接受到请求之后，将该服务状态置位下线。
服务注册中心
1.失效剔除，有些时候，我们的服务实例并不一定会正常下线，可能由于内存溢出、网络故障等原因使得服务不能正常工作，而服务注册中心并未收到“服务下线”的请求。为了从服务列表中将这些无法提供服务的实例剔除，Eureka Server在启动时会创建一个定时任务，默认每隔一段时间将当前清单中超时没有续约的服务剔除。
2.自我保护，Eure Server在云心期间，会统计心跳失败的比例在15分钟之内是否低于85%，如果出现低于的情况，Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过期。
客户端的负载均衡
负载均衡通常都是指服务端的负载均衡，其中分为硬件负载均衡和软件负载均衡。硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备，比如F5等；而软件负载均衡则是通过在服务器上安装具有负载功能或模块的软件来完成请求的分发工作，比如Nginx等。下图是服务器负载均衡的架构方式：
硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳机制检测来剔除故障的服务端节点以保障清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备的时候，该设备按某种算法从维护的可用服务端清单中取出一台服务端地址，然后进行转发。
而客户端负载均衡和服务端负载均衡最大的不通电在于上面所提到的服务清单所存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单。
RestTemplate对象会使用Ribbon的自动化配置，同时通过配置@loadbalance还能开启客户端负载均衡。
Spring Retry
1.对于互联网的服务调用，通常情况下我们需要对某些服务进行重试策略，比如重试多少次失败则返回错误信息，当然可重试服务接口必须要自己实现幂等。不然由于网络或者其他原因导致请求时间过长导致重复操作，会出现我们不需要的结果
2.在Spring中有个很经典的框架就是Retry，使用非常简单，只需要加上@EnableRetry启用重试机制，并且@Retryable注解配置重试所需要的服务即可，可以自定义重试的异常信息、重试次数以及重试策略执行的周期、重试的线程数。并且在最终重试次数都完成调用仍然调用失败时，我们可以使用@Recover注解来完成最终的记录和补偿处理。
3.注意：但是重试策略会有单点问题，我们必须要配合持久化的相关标识来判断单点问题的重试策略是否搞定了，不然我们没有达到使用Spring retry的效果，当然了，我们基于Ribbon的重试则不会存在该问题，即使存在也不需要重点考虑。因为我们仅仅是http服务调用请求而已，并不是持久化操作或者涉及其他相关核心操作。
Spring cloud Hystrix断路器
在微服务架构中，我们将系统拆分成了一个个的服务单元，各个单元应用间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能应为网络原因或者是依赖服务自身问题出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会出现因等待出现故障的依赖方响应而形成任务的积压，线程资源无法释放，最终导致自身服务的瘫痪，进一步甚至出现故障的蔓延最终导致整个系统的瘫痪。如果这样的架构存在如此严重的隐患，那么相较传统架构就更加不稳定。为了解决这样的问题，因此产生了断路器等一系列的服务保护机制。
针对上述问题，在Spring Cloud Hytrix中实现了线程隔离、断路器等一系列的服务保护功能。它也是基于Netflix的开源框架Hystrix实现的，该框架目标在于通过控制那些访问远程系统、服务和第三方的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备了服务降级、服务熔断、线程隔离、请求缓存、请求合并以及服务监控等强大的功能。