Spring Cloud简单理解

一、Spring Cloud

Spring Cloud，微服务架构。包括 服务发现（Eureka）、断路器（Hystrix）、服务网关（Zuul）、客户端负载均衡（Ribbon）、服务跟踪（Sleuth）、消息总线（Bus）、消息驱动（Stream）、批量任务（Task）等。

二、微服务

微服务的核心思想就是服务拆分与解耦，降低复杂性。微服务强调将功能合理拆解，尽可能保证每个服务的功能单一，按照单一责任原则（Single Responsibility Principle）明确角色。各个服务做到灵活、可复用，亦可根据各个服务自身资源需求，单独部署，单独作横向扩展。

三、服务注册与发现 Eureka

1.@EnableEurekaServer 注解启动一个服务注册中心提供给其他应用进行对话。这个注解放在启动类上方。

2.Eureka分为服务注册中心，服务提供者，服务消费者。服务消费者都必须指定注册中心。服务提供者提供服务，而服务消费者可以调用提供者的服务。

3.服务发现的接口DiscoveryClient类是Spring Cloud对服务治理做的一层抽象。
@EanbleDiscoveryClient注解，加在启动类main的上方，可以将应用注册为Eureka客户端应用，以获取服务发现的能力。

4.Spring Cloud Consul项目：可以将基于Spring Boot的微服务应用注册到Consul上，并通过此实现微服务架构中的服务治理。Consul的作用类似于Eureka。

5.下面是Eureka的治理机制：

服务提供者

服务注册：启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。
服务续约：在注册完服务之后，服务提供者会维护一个心跳机制用类持续告诉Eureka Server：“我还活着”。
服务下线：当服务实例进行正常的关闭操作是，它会触发一个服务下线的REST请求给Eureka Server，告诉服务注册中心：“我要下线了”。

服务消费者

获取服务：当我们强消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单
服务调用：服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。在进行服务调用的时候，优先访问同处一个Zone中的服务提供方。

Eureka Server（服务注册中心）：
失效剔除：默认每隔一段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除出去。
自我保护：Eureka Server在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%（通常由于网络不稳定导致）。Eureka Server会将当前的实例注册信息保护起来，会让这些实例不会过期，尽可能的保护这些注册信息。
PS：总感觉这个“失效剔除”和“自我保护”，有些矛盾。。

6.同样作为注册中心，Eureka和Zookeeper的区别是什么？
分布式事务的CAP的理论，C是一致性，A是可用性，P是分区容错性（必备）。
Eureka是AP，注重可用性。
而Zookeeper是cp，注重一致性。

四、服务消费者

1.服务消费者 Ribbon

1.LoadBalancerClient接口，是一个负载均衡客户端的接口。
Ribbon注解：@LoadBalanced。
2.RestTemplate对象,通过getForObject()等方法实现对服务提供者接口的调用。
注入方式如下：

@Autowired
private RestTemplate restTemplate;

可用方法如下：

getForObject(URI uri,Class<T> responseType)

3.将eureka-server(服务注册中心) 、eureka-client(服务提供者)，eureka-consumer(服务消费者)都启动起来，然后访问eureka-consumer的Controller层方法对应的请求，可以观察eureka-consumer服务是如何消费eureka-client服务的Controller层方法接口的。

4.使用Spring Cloud Ribbon可以作为服务消费者，实现服务的调用以及客户端的负载均衡。

5.在Ribben中可以采用服务名的方式进行请求，因为Ribbon有一个拦截器，它能够在这里进行实际调用的时候，自动的去选取服务实例，并将实际要请求的IP地址和端口替换这里的服务名，从而完成服务接口的调用。

6.Ribbon底层原理：负载均衡，轮询

7.Ribbon：重试机制。
Eureka由于在可用性和一致性的取舍上，选择了可用性。所以服务调用遇到实例故障时，可以使用重试机制。Ribbon的重试机制可以通过简单的配置实现。
spring.cloud.loadbalancer.retry.enabled=true

2.服务消费者Feign

1.Feign是一套基于Netflix Feign实现的声明式服务调用客户端。Feign可以作为服务消费者。需要通过创建接口并用注解来配置它既可完成对Web服务接口的绑定。

2.@EnableFeignClients注解在Application接口上方，可以开启扫描Spring Cloud Feign客户端的功能

3.@FeignClient注解用在Feign接口上方，用来指定这个接口所调用的服务名称。

4.Feign底层原理：动态代理

5.Feign接口支持SpringMvc的注解。包括@RequestBody,@RequestParam等

6.重试机制：Feign自带Ribbon，默认实现了请求重试机制。当请求时间超过设置的超时时间时，Feign会发起重试。

7.使用Frign的时候，同时也会自动创建负载均衡的Ribbon，还会自动引入服务保护与容错的Hystrix

8.Feign最终发送request请求以及接受response响应，都是由Client组件完成的，其中Client的实现类，只要有Client.Default,该类由HttpURLConnection实现网络请求，另外还支持HttpClient、Okhttp。

五、断路器 Hystrix

1.服务熔断： 在分布式架构中，当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。

雪崩效应：是一种因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程。

熔断可以避免服务雪崩。

2.Spring Cloud中使用了Hystrix 来实现断路器的功能。Hystrix具备拥有回退机制和断路器功能的线程和信号隔离，请求缓存和请求打包，以及监控和配置等功能。Hystrix具有融断机制。

Hystrix可以进行服务降级、服务隔离、服务熔断。

3.在Ribbon中需要引入Hystrix依赖。否则服务不可用时，会返回404。

而Feign中已经依赖了Hystrix，不需要再引入，会直接返回内部错误(500) 。

4.@SpringCloudApplication注解，它整合了@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker。

5.当服务提供者不可用时，断路器Hystrix会返回错误响应。

6.使用了@HystrixCommand来将某个函数包装成了Hystrix命令，这里除了定义服务降级之外，Hystrix框架就会自动的为这个函数实现调用的隔离。所以，依赖隔离、服务降级在使用时候都是一体化实现的.

@HystrixCommond，顾名思义，使用了“命令模式”。

Hystrix一般都是和Feign一起使用，使用@HystrixCommond的较少。

7.服务隔离： Hystrix使用"舱壁模式"实现线程池的隔离，它会为每一个Hystrix命令创建一个独立的线程池，这样就算某个在Hystrix命令包装下的依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他的服务。
通过对依赖服务实现线程池隔离，应用更加健壮，不会因为个别依赖服务出现问题而引起非相关服务的异常。

8.服务降级：当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。

为了保证重要或基本的服务能正常运行，我们可以将一些不重要或不紧急的服务或任务进行服务的延迟使用或暂停使用。

9.思考：服务降级和服务熔断有什么区别？

熔断是直接返回一个错误响应，降级是延迟使用或暂停使用。

10.Hystix隔离机制：线程池隔离、信号量隔离。

11.可以在熔断的FallBack方法中，将Throwable异常作为参数，并显示熔断的异常信息。

15.Hystrix-dashboard，可以对服务进行监控，展示数据。