微服务 部分组件 思考知识点 记录

在单一服务的项目中，如果使用restTemplate调用三方接口，考虑到三方接口不稳定的情况， 需要对调用三方服务失败的情况进行处理。

可以考虑使用熔断器搭配restTemplate的方式处理服务调用失败的情况。

在pom文件导入hystrix坐标， 启动类激活hystrix。 接着，在使用restTemplate调用三方接口的方法A上使用@HystrixCommand注解。

在@HystrixCommand注解中， fallbackMethod 对应拖地方法。 在托底方法中， 保证方法参数和方法A一致， 最后方法参数最后添加一个参数, Throwable.

如果方法A是    String  A(String a)  ,  则托底方法为  String A_fallback(String a , Throwable throwable) , 这样，当三方接口发生异常调用不到的时候，触发降级操作，程序开始走熔断方法，这时候想打印异常 

信息的话，就从Throwable里去拿。

 

在使用了Hystrix后， 可以使用ribbon和restTemplate搭配的方式进行三方服务调用。 restTemplate提供调用操作， ribbon提供负载均衡。

可以使用DiscoveryClient来获取在注册中心注册的服务， 只需要把服务名提供给DiscoveryClient ， 但是如果是集群的话，一个服务名可以对应多个服务。 这时候DiscoveryClient获取到的是一个服务列表。通过服务名来获取一个服务列表，这个列表中有众多的相同服务。那么，到底要调用哪个服务才好？

可以用： 

List<ServiceInstance> serverList = discoveryClient.getInstances("PROVIDER-SERVER");
ServiceInstance server = serverList.get(0);

来解决。

但是 ， 总不能所有请求都调用从列表中取到的第一个服务吧。 

也就是说， 使用DiscoveryClient的方式，只能获取对应服务名称的全部服务。 但是没有负载均衡 ， 需要自己写负载均衡策略。 而最简单的随机， 轮询，权重， 可以写， 但总是不够好。应为还有更好的策略。比如有一种策略，忘了名字， 实现原理是： 假设有3个服务A B C  ， 始终将请求发送给服务压力最少的那个服务。（可以使用全局变量标记当前服务正在处理的请求个数， 或者直接监控线程池使用中的线程个数）， 当有一个新的请求到来时， 对比 A B C三个服务，那个服务线程池中始终中的线程数目最少就把请求给那个服务。

还有一种策略是可以带重试操作的负载均衡策略。比如有三个服务 A B C  ， 有一个请求到来，负载均衡策略将请求转发给A服务，但是A服务由于网络故障或其他原因拒绝提供服务。 这时候策略可以进行重试操作，再一次向服务A发出请求，如果A此时提供服务，则请求完成。 如果A此时仍未提供服务， 策略再次进行重试，如果连续三次服务A都不能够提供服务，那么就会将请求转发给B服务执行同样的请求操作。

如果A请求连续对N次请求都不能产生有效的响应，则策略认为A服务宕机，此后的请求不会再转发给A服务。 与此同时，策略还会对A不定时的进行回访，每隔N秒对之间宕机的服务A进行访问， 如果服务A重新恢复正常并可以提供有效服务， 则策略重新将服务A拉入可转发服务列表。

当然，这些策略实现起来麻烦，使用DiscoveryClient的方式需要自己实现这些策略。

我们转而使用hystrix提供的另一个实例： LoadBalancerClient 。 LoadBalancerClient是一个自带负载均衡的实例。（类似于在自动注入的restTemplate上加注解@Loadbanlance）, 我们同样LoadBalancerClient提供服务名， 但这次LoadBalancerClient不会像DiscoveryClient一样给我们返回一个服务列表， 我们在使用choose方法时， 参数传一个服务名， 而LoadBalancerClient返回的则是一个ServiceInstance对象，注意，是单独的一个ServiceInstance对象， 也就是意味着， LoadBalancerClient的choose方法为我们从服务的众多服务中通过他自配的负载均衡策略为我们挑选了一个服务。 我们可以不用自己实现负载均衡策略。我们只需要拿到服务ServiceInstance ， 然后获取ip 端口， 拼接出一个url。 调用就行。

当然，这些方法都是比较原生的， 都不如fegin来的轻巧简洁。

对于学习分布式而言， 1：服务的注册与发现   2：请求方式openFeign  3：熔断器   4：路由  这几个还是一定要看看的。

这段时间手里活比较少， 与其天天摸鱼， 不如学点东西充实自己， 自己学的东西以后可以用在项目中。 

相信自己在不久的未来， 一定可以写出优秀的可以拿出来让同行观摩的代码。