Cool带你学治理体系-5

ZK负载均衡故障转移

在使用ZK作为注册中心时，故障的发现是由Zk去进行发现，业务逻辑层通过watch的心跳机制将自己注册到zk上，网关对zk进行订阅就可以知道有多少可以调用的列表。当业务逻辑层在重启或者被关闭时就会跟zk断了心跳，zk会更新可调用列表。

使用zk作为负载均衡的协调器，最大的问题是zk对于服务是否可用是基于pingpong的方式，只要服务心跳存在，zk就认为服务是处在于可用状态，但是服务如果处在于假死的状态，zk是无从得知的。这个时候，业务逻辑服务是否真正可用只能够由网关知道。

幂等设计

为何会牵出幂等设计的问题，主要是因为负载均衡的failover策略，就是对失败的服务会进行重试，一般来说，如果是读操作的服务，重复执行也不会出问题，但想象一下，如果是一个创建订单减库存的操作，第一次调用也tomcat1超时，再重新调用了tomcat2，这个时候我们都不能确认超时调用的tomcat1是否真的被调用，有可能根本就调用不成功，有可能已经调用成功但是因为某些原因返回超时而已，所以，很大程度这个接口会被调用2次。如果我们没有保证幂等性，就有可能一个订单导致了减少2次的库存。所谓的幂等性，就是得保证在同一个业务中，一个接口被调用了多次，其导致的结果都是一样的。

服务限流降级熔断

先来讲讲微服务中限流/熔断的目的是什么，微服务后，系统分布式部署，系统之间通过rpc框架通信，整个系统发生故障的概率随着系统规模的增长而增长，一个小的故障经过链路的传递放大，有可能会造成更大的故障。

限流跟高可用的关系是什么，假定我们的系统最多只能承受500个人的并发访问，但整个时候突然增加到1000个人进来，一下子就把整个系统给压垮了，本来还有500个人能享受到我们系统的服务，突然间变成了所有人都无法得到服务，与其让1000人都不法得到服务，不如就让500个人得到服务，拒绝掉另外500个人。限流是对访问的隔离，是保证了部门系统承受范围内用户的可用性。

熔断跟高可用的关系是什么，上面说了微服务是一个错综复杂的调用链关系，假设 模块A 调用 模块B ， 模块B 又调用了 模块C ， 模块C 调用了 模块D，这个时候，模块D 出了问题出现严重的时延，这个时候，整个调用链就会被 模块D 给拖垮，A 等B，B等C，C等D，而且A B C D的资源被锁死得不到释放，如果流量大的话还容易引起雪崩。熔断，主动丢弃 模块D 的调用，并在功能上作出一些降级才能保证到我们系统的健壮性。 熔断是对模块的隔离，是保证了最大功能的可用性。