6. 常见的服务治理策略
干货：
服务容错: 故障转移/快速失败/故障恢复等
流量控制：滑动时间窗口/令牌桶/分布式限流等
1. 服务容错
通过一张图一目了然：
容错设计模式：
1. 断路器模式
断路器的基本思路是很简单的，就是通过代理（断路器对象）来一对一地（一个远程服务对应一个断路器对象）接管服务调用者的远程请求。断路器会持续监控并统计服务返回的成功、失败、超时、拒绝等各种结果，当出现故障（失败、超时、拒绝）的次数达到断路器的阈值时，它状态就自动变为“OPEN”，后续此断路器代理的远程访问都将直接返回调用失败，而不会发出真正的远程服务请求。通过断路器对远程服务的熔断，避免因持续的失败或拒绝而消耗资源，因持续的超时而堆积请求，最终的目的就是避免雪崩效应的出现。由此可见，断路器本质是一种快速失败策略的实现方式，它的工作过程可以通过下面图来表示：
从调用序列来看，断路器就是一种有限状态机，断路器模式就是根据自身状态变化自动调整代理请求策略的过程。一般要设置以下三种断路器的状态：
- CLOSED：表示断路器关闭，此时的远程请求会真正发送给服务提供者。断路器刚刚建立时默认处于这种状态，此后将持续监视远程请求的数量和执行结果，决定是否要进入 OPEN 状态。
- OPEN：表示断路器开启，此时不会进行远程请求，直接给服务调用者返回调用失败的信息，以实现快速失败策略。
- HALF OPEN：这是一种中间状态。断路器必须带有自动的故障恢复能力，当进入 OPEN 状态一段时间以后，将“自动”（一般是由下一次请求而不是计时器触发的，所以这里自动带引号）切换到 HALF OPEN 状态。该状态下，会放行一次远程调用，然后根据这次调用的结果成功与否，转换为 CLOSED 或者 OPEN 状态，以实现断路器的弹性恢复。
这些状态的转换逻辑与条件如下图所示：
OPEN 和 CLOSED 状态的含义是十分清晰的，与我们日常生活中电路的断路器并没有什么差别，值得讨论的是这两者的转换条件是什么？最简单直接的方案是只要遇到一次调用失败，那就默认以后所有的调用都会接着失败，断路器直接进入 OPEN 状态，但这样做的效果是很差的，虽然避免了故障扩散和请求堆积，却使得外部看来系统将表现极其不稳定。现实中，比较可行的办法是在以下两个条件同时满足时，断路器状态转变为 OPEN：
- 一段时间（譬如 10 秒以内）内请求数量达到一定阈值（譬如 20 个请求）。这个条件的意思是如果请求本身就很少，那就用不着断路器介入。
- 一段时间（譬如 10 秒以内）内请求的故障率（发生失败、超时、拒绝的统计比例）到达一定阈值（譬如 50%）。这个条件的意思是如果请求本身都能正确返回，也用不着断路器介入。
以上两个条件同时满足时，断路器就会转变为 OPEN 状态。
断路器做的事情是自动进行服务熔断，这是一种快速失败的容错策略的实现方法，也是一种典型的服务降级策略。举个例子：你女朋友被前男友约出去了，你打她手机没人接，你气冲冲地的挂断后（快速失败），然后你有打了另外三个你女朋友闺蜜的手机号（故障转移），都还是没能找到你女朋友（重试超过阈值）。这时候你非常生气地在微信上给她留言“三分钟不回电话就分手”，以此来与你取得联系。原谅我这么举例，虽然不太吉利，但是你给你女朋友留言这个行为便是服务降级逻辑。
其他服务治理的工具，譬如Envoy、istio等也同样会包含有类似的设置。
2. 重试模式
重试模式适合解决系统中的瞬时故障，简单的说就是有可能自己恢复（Resilient，称为自愈，也叫做回弹性）的临时性失灵，网络抖动、服务的临时过载（典型的如返回了 503 Bad Gateway 错误）这些都属于瞬时故障。重试模式实现并不困难，即使完全不考虑框架的支持，靠程序员自己编写十几行代码也能够完成。在实践中，重试模式面临的风险反而大多来源于太过简单而导致的滥用。我们判断是否应该且是否能够对一个服务进行重试时，应同时满足以下几个前提条件：
- 仅在主路逻辑的关键服务上进行同步的重试，不是关键的服务，一般不把重试作为首选容错方案，尤其不该进行同步重试。
- 仅对具备幂等性的服务进行重试。
- 重试必须有明确的终止条件，常用的终止条件有两种：
- 超时终止
- 次数终止
由于重试模式可以在网络链路的多个环节中去实现，比如客户端发起调用时自动重试，网关中自动重试、负载均衡器中自动重试，等等，而且现在的微服务框架都足够便捷，只需设置一两个开关参数就可以开启对某个服务甚至全部服务的重试机制。
2. 流量控制
与容错模式类似，对于如何进行限流，也有一些常见的设计模式可以参考使用，本节将介绍滑动时间窗、令牌桶以及分布式限流三种限流设计模式。
1. 滑动时间窗口
有一个滑动时间窗口算法，在计算机科学的很多领域中都有成功的应用，比如著名的TCP协议的流量控制等都是使用这个算法实现流控的。具体实现大概可以想象下就是在不断向前流淌的时间轴上，漂浮着一个固定大小的窗口，窗口与时间一起平滑地向前滚动。任何时刻静态地通过窗口内观察到的信息，都等价于一段长度与窗口大小相等、动态流动中时间片段的信息。由于窗口观察的目标都是时间轴，所以它被称为形象地称为“滑动时间窗模式”。
滑动时间窗口模式可以保证任意时间片段内，只需经过简单的调用计数比较，就能控制住请求次数一定不会超过限流的阈值，在单机限流或者分布式服务单点网关中的限流中很常用。不过，这种限流也有其缺点，它通常只适用于否决式限流，超过阈值的流量就必须强制失败或降级，很难进行阻塞等待处理，也就很难在细粒度上对流量曲线进行整形，起不到削峰填谷的作用。
2. 令牌桶
假设我们要限制系统在 X 秒内最大请求次数不超过 Y，那就每间隔 X/Y 时间就往桶中放一个令牌，当有请求进来时，首先要从桶中取得一个准入的令牌，然后才能进入系统处理。任何时候，一旦请求进入桶中却发现没有令牌可取了，就应该马上失败或进入服务降级逻辑。与此同时令牌桶也有最大容量限制，这意味着当系统比较空闲时，桶中令牌累积到一定程度就不再无限增加，预存在桶中的令牌便是请求最大缓冲的余量。上面这段话，可以转化为以下步骤：
- 让系统以一个由限流目标决定的速率向桶中注入令牌，比如要控制系统的访问不超过 100 次，速率即设定为 1/100=10 毫秒。
- 桶中最多可以存放 N 个令牌，N 的具体数量是由超时时间和服务处理能力共同决定的。如果桶已满，第 N+1 个进入的令牌会被丢弃掉。
- 请求到时先从桶中取走 1 个令牌，如果桶已空就进入降级逻辑。
桶：bucket 速率：rate
令牌桶模式的实现看似比较复杂，每间隔固定时间就要放新的令牌到桶中，但其实并不需要真的用一个专用线程或者定时器来做这件事情，只要在令牌中增加一个时间戳记录，每次获取令牌前，比较一下时间戳与当前时间，就可以轻易计算出这段时间需要放多少令牌进去，然后一次性放入即可，所以真正编码并不会显得很复杂。
3. 分布式限流
一种常见的简单分布式限流方法是将所有服务的统计结果都存入集中式缓存（如 Redis）中，以实现在集群内的共享，并通过分布式锁、信号量等机制，解决这些数据的读写访问时并发控制的问题。在可以共享统计数据的前提下，原本用于单机的限流模式理论上也是可以应用于分布式环境中的，可是其代价也显而易见：每次服务调用都必须要额外增加一次网络开销，所以这种方法的效率肯定是不高的，流量压力大时，限流本身反倒会显著降低系统的处理能力。
anyway，出现问题解决它就好了，但是你不能因为它一两个缺点就不用，我觉得这不是一个程序员良好的做事风格，能扛事的人一般都是能成大事的人。
3. 小结
服务治理的话题随便拿出一个来研究就能让你增长不少见识，所以说大家下去有时间可以专门研究下相关的服务或者产品，比如我们提到的envoy以及istio等，看下它们是如何做到全部或者部分治理的，博采众长，才能脱胎换骨，加油。
