微服务小记

Eureka

微服务，就是分布式+集群
每一个服务可能都在不同的主机上，具有一个IP地址和端口
这样就会出现以下问题：

1，多个主机提供同一个服务，就会有服务下线和服务上线，比如故障和扩容，新增机器等等
2，代码中请求服务的IP和端口不可以写死，因为每次不一定调用哪一个主机的服务，肯定会变动的，一旦变动，写死的代码就需要人工去一个个修改了
3，既然一直会变动，就需要维护和管理了，谁来管理？

Eureka出现了，这就是一个服务的注册中心，管理维护服务的上线和下线，调用方可以向Eureka请求一份服务列表，表中包括服务名和提供该服务的所有主机IP+端口
Eureka服务注册中心通过心跳的方式维护服务列表，比如一分钟发送一次心跳通信，这就可能出现有的服务因故障下线了，Eureka尚未移除该服务，这时候请求服务列表的一方就会拿到这个包含故障服务器的列表，后续就难免会去调用已下线的服务

Ribbon

如果一个服务有多台主机提供，那么如何进行选择呢？这就是负载均衡，你应该听过nginx，这是服务端的负载均衡
另外还有客户端的负载均衡，就是Ribbon，在获取了主机列表后，从中选择一个进行调用，这就涉及到选择的策略了，包括随机，轮转，响应时间等等

Hystrix

微服务的架构会造成存在多重调用的现象，而每一个微服务都可能会故障，延迟，从两个角度进行考虑：
1，A调用B，而B需要调用C，C又需要调用D······
2，A调用B，之后要调用C，再之后调用D······
现实中，这两种现象会叠加。
对于1，如果D出问题了，延迟会逐步传递到A，这个时候请求多的话，A就会堆积大量请求，都会同样卡住，资源（线程资源）耗尽崩溃
对于2，调用B延迟了，后面的所有调用都会延迟，这个时候，A也会堆积大量的请求，资源耗尽崩掉
延迟和故障会在整个分布式系统中蔓延···
这样的调用路径就像一个线路，在A调用B时，由于B的故障，没有及时反馈错误信息，导致A卡住，造成大量请求积压
这个时候，A线程资源容易耗尽，属于半死不活的那种，处于崩溃边缘，B更不可靠更没指望了，这种时候考虑的不是拯救A和B了，而是考虑拯救那些请求A的服务（甚至可能是更更前面的服务），他们也在等待，也卡住了
如果能够在这种情况下让A及时反馈错误信息，就可以让请求A的所有人及时得到反馈，从而选择另一个主机进行请求

注意了，为了避免A资源耗尽，熔断的是A，虽然故障的是B

现实中，可能是A熔断的同时，请求A的一些服务也熔断一些，甚至再往前的服务也熔断，一个链条上的多个服务方，都熔断自己
这个线路就被打破了，也就是下面的circuit breaker

In a microservice architecture it is common to have multiple layers of service calls.
Netflix has created a library called Hystrix that implements the circuit breaker pattern. 

所以，Hystrix是运行在哪一端的？请求方还是服务提供方？
答案是服务提供方，原理是去请求其他服务结果失败了很多次，达到阈值，就会熔断自己，避免己方系统请求积压然后崩溃再造成整个系统的崩溃
Hystrix设定的熔断是5秒20个请求失败，给后续的请求方直接返回错误信息

总结起来，熔断机制，是自己依赖的下游服务故障触发自我熔断，避免引发系统性崩溃
那么Hystrix如何收集请求失败成功的信息？当然是请求要在Hystrix监控下进行，即让Hystrix来代理一下
将请求使用Hystrix包装一下，通过Hystrix进行发送
基本上与Ribbon一起使用

Feign

这玩意就是整合了Hystrix和Ribbon，简化开发

熔断，降级，限流：

限流：限制并发的请求访问量，超过的拒绝；
降级：服务分优先级，牺牲非核心服务，保证核心服务稳定；从整体负荷考虑；
熔断：依赖的下游服务故障触发自我熔断，避免引发本系统崩溃；系统自动执行和恢复；