标签：move rop 了解 inter command 构造 初始 自动化 默认
服务治理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
前面
标签：move rop 了解 inter command 构造 初始 自动化 默认
原文地址：https://www.cnblogs.com/scru/p/11587199.html
