spingcloud组件注解汇总

服务治理Eureka

Eureka注册中心配置

@EnableEurekaServer：启动服务注册中心

application.properties里面的配置，服务名 spring.application.name ,注册中心注册名eureka.instance.hostname, 服务端口server.port,是否要像注册中内心注册本身eureka.client.register-with-eureka, 是否要检索服务eureka.client.fetch-registry

注册中心的做用：

1.剔除过时服务

2.服务同步

3.传播下线事件

Eureka Client

@EnableDiscoveryClient:激活Eureka中的DiscoveryClient的实现

因为服务可部署多个实例，ribbon轮询的时候先找到该服务，再找到该服务实例，因此服务地址存放在一个双层map中，第一层key是服务名，第二层key是具体服务的实例名。

EurekaClient做用：

1.向注册中心注册

2.服务续约

3.服务下线

4.查询服务列表

 

 

 

 Ribbon

负载均衡Ribbon基于TCP和HTTP的客户端负载均衡器，经过ribbonServerList服务端列表去轮询访问以达到负载均衡的做用。

建立RestTemplate实例，并在上面加上注解@Bean和@LoadBalanced开启客户端负载均衡。

ribbon源码分析，所谓负载均衡本质就是在客户端发出请求前将其拦截，找到存在客户端本地的服务端列表，经过某种负载均衡方式，默认是轮询，挑选服务实例执行请求。

让咱们本身静下心想想，springcloud设计时须要提供负载均衡功能，ribbon只是一种经常使用的实现负载均衡的组件，不免往后会有其余的替代品。故而在sprigcloud中留有一个接口专门让客户端负载均衡器来实现，这个接口叫LoadBalancerClient。

客户端负载均衡器在本地存有一份双层map的实例清单，第一层map的key值为服务名，第二层存放具体的实例。实现负载均衡须要三步，

第一步，根据服务名选择服务实例。

第二步，被挑选的实例执行请求内容。

第三步，从新构造URI，把URI中写的服务名替换成实际的带有ip，port的名字。

只在须要负载均衡的restTemplate中加上@LoadBalanced，便可实现负载均衡的话，那在这里面必定是用到了springboot的自动配置原理。咱们要关注几个有条件的注解，

@ConditionalOnClass和@ConditionalOnBean。在负载均衡自动配置类中，LoadBalancerAutoConfiguration的自动加载必须有RestTemplate类存在于当前环境工程中，spring的bean工程中必须有LoadBalancerClient实现Bean的存在。

在自动化配置类LoadBalancerAutoConfiguration中，主要实现了三件事。这三件事都是有关联的

第一件，建立LoadBalancerInterceptor,  里面有拦截的具体方法

第二件，建立RestTemplateCustomizer的bean，用于给RestTemplate增长拦截器

第三件，维护List<RestTemplate>，并初始化，遍历该列表，给每个RestTemplate增长了LoadBalancerInterceptor

因为每一个RestTemplate中都增长了拦截器，restTemplate执行请求时会被intercept方法拦截，根据服务名，调用execute函数来选择实例并发起实际的请求。

 

 Hystrix

为何须要熔断器？

由于服务之间的互相调用，不免会出现失败的状况，A服务调用B，B出现故障，若是此时对A服务方法大量调用，造成任务积压，则可能致使A服务失效。

熔断器就是给方法设置一个超时时间，timeOutInMissiseconds，到了超时时间，方法还没执行完，就执行设置的默认方法，或者直接熔断。

让咱们来想一想，若是咱们设置熔断会如何，其实就是监视方法，计算调用时间，若是超时，则报错或者执行降级服务。这个地方须要用到命令模式，将每一个请求都看作是一个命令，方法是一个执行者，二者中间须要一个协调者，决定是否要控制并发量接收该命令，决定如何撤回该命令。

咱们先了解下hystrix的执行流程

1.将请求封装成hystrixCommand或者是hystrixObservableCommand

2.执行命令，同步或者异步两种方式

3.判断该请求是否在缓存中，若是在直接返回，否则进入下一步

4.判断断路器是否打开，若是已打开，直接返调用服务降级回调方法。若是没打开，进入下一步

5.判断是否有足够的线程池中的线程或者信号量来执行方法，没有则调用降级方法，并计算是否要打开断路器。若是有，进入下一步

6.执行调用的方法，若是方法失败或者超时，执行降级方法，并计算是否要开启断路器；若是执行成功，hystrix在记录日志并采集监控报告以后将结果返回。

服务降级方法须要实现通用的响应结果，通常是从缓存中获取，或者是静态逻辑获取。若是须要经过网络获取，则该服务降级方法也要包裹成一个hystrixCommand，从而生成级联的降级策略。

3.1

如何开启hystrix缓存？

在@HystrixCommand注解上加上@CacheResult注解，标记缓存返回的结果，key值是全部请求参数。或者重写getCacheKey方法，让其返回非null的key。HystrixCommand类里面getCacheKey方法返回的是null。

如何清除失效缓存？

在update方法上加上@CacheRemove注解，并用commandKey在里面指定失效的是哪个请求命令。或者在HystrixCommand的实现类里调用请求命令的缓存清除。

如何将某特定请求参数做为缓存的key值？

能够在参数前加上@CacheKey或者在@CacheResult里面定义一个方法CacheKeyMethod指定专门生成key的方法。

断路器中有三个方法，4.1.判断断路器是否打开(isOpen) 4.2.闭合断路器  4.3.判断请求是否被容许。

4.1.1 断路器打开标志是开，直接返回true。

4.1.2 断路器打开标志为关，判断请求量是否大于阈值，而且失败率大于阈值，若是都大于则CAS将断路器设置为打开，并返回true。

4.3.1 若是设置了强制打开断路器，则不容许请求；若是强制关闭断路器，会运行请求，但也会执行isOpen，来执行计算断路器是否打开的逻辑。

4.3.2 若是没有设置强制打开或者强制关闭，若是断路器关闭容许经过，或者allowSingleTest返回true也容许请求经过。

4.3.3 allowSingleTest即给断路器设置了一个休眠时间，默认5S，若是断路器距离上一次设置的时间超过5S,则尝试请求经过，若是请求仍是失败，则等待下一个休眠窗口过去再重试。这种方式称为半打开。

什么状况会形成断路器打开？

请求总数（QPS）和失败比例超过阈值。

什么状况会让断路器由打开改成关闭呢？

断路器每隔一段时间，就会容许请求经过，称为半打开，若是请求执行成功，断路器则关闭。

什么状况会放请求进来？

断路器闭合或者休眠窗口刚过去。

半打开状态会放多少请求进来？

休眠窗口过去的第一个请求，容许请求访问，并用CAS设置最新的请求尝试时间，在CAS设置成功以前的请求都会被放进来容许访问。

何时会触发服务降级？

断路器熔断，线程池或信号量资源不够，方法执行错误，抛出除HystrixBadRequestException以外的错误，方法执行超时

有没有办法方法执行错误时，不会调用服务降级？

有的，设置@HystrixCommand里的ignoreExceptions参数便可

5.1 Hystrix采用线程池隔离技术，每一个依赖服务建立一个独立的线程池。

 

  Feign

前面