w11- 总结 - 关于熔断

如果服务节点出现故障，通常来讲，应该将故障节点摘除的，以防止被分配到给节点的用户请求出现失败；同时也可以防止故障恶化。



nginx

比如我们的前端load balancer是nginx实现的，可以让运维手动将的故障节点重cluster配置中除去。但显然这是一种效率极低的方法。摘除的过程需要自动化来完成。这样就需要一个health check的服务的接口来使得nginx自动发现节点的健康状况。health check 的实现可用有多种方式，通常包括：

1. 检查服务节点的端口

2. 发送一个简单的http请求，期望返回的结果是status code = 200.



这样一个简单模型已经能够完成熔断的需求。但在真实的世界还不够。因为通常要考虑几个问题

1. 故障节点是否可以自动恢复。

2. health check服务本身故障了怎么办？



对于第1个问题，nginx会定期进行health check，如果故障恢复了，会把改节点重新接入流量。

但对于第2个问题的，可能导致的问题是，虽然服务节点没有问题，但会导致不接入流量。如果只是部分节点的问题，没有太大的影响，但如果全部的节点的health接口都有问题（为什么？比如配置错误了。），就会导致服务整体失败。看起来是一个愚蠢的问题。

AWS的ELB中，将所有的目标失败的时候，认为所有都成功，可以正常接收流量。这是一种比较不错的策略。



其他：

基本上load balancer都可以实现类似的功能的，包括在service mesh/k8s中。

在k8s中的，kubelet会通过probes探测所有的pod的liveness状态，根据状态修改load balance的endpoint.

linkerd2(service mesh)使用通道load balance的算法，实现流量摘除的功能。



熔断与限流的区别

熔断与限流其实还是有点相似的。相同的地方是，都限制了用户的访问，是客户端返回错误的结果。区别自安于熔断是由于后端的故障触发的拒绝访问，限流由于用户请求超出规则限制触发的拒绝访问。