服务治理通常是指通过限流、熔断等手段，保障微服务的可靠运行，即运行时治理。更加宽泛的服务治理还包括微服务持续集成（开源软件管理、自动化测试等），微服务部署最佳实践（滚动升级、灰度发布等），微服务可观测性能力（日志、监控、告警等）构建等。

微服务治理专题主要探讨运行时治理。接下来我们探讨故障处理的一般性原则。

系列文章：

服务治理-微服务常见故障模式
服务治理-隔离仓的作用

故障识别

在用户看来，故障场景和正常场景是非常容易区分的。在服务治理的角度，识别故障则非常困难。

以调用超时为例，产生调用超时的原因非常多，包括：（1）服务端部分接口处理慢，导致超时，而其他接口处理正常；（2）服务端故障，网络不可达，可能是短暂的，也可能是持续的；（3）服务端内存、CPU高，导致处理变慢；（4）大量并发请求在服务端排队，当请求被处理的时候，已经超过了很长的时间；（5）客户端并发建立连接，内存、CPU增高，导致请求握手超时等。这些不同类型的错误，从调用者看起来，都体现为一样的行为。

以错误码为例，服务端返回503错误，也可能包含很多不一样的原因。比如系统未就绪，正在启动过程中，下次重试就可以访问；或者服务出现内存泄漏等原因，导致无法进行响应；当服务内部的一些部件不可用的时候，也可能返回503错误码。
基于上述原因，服务治理能够识别少量的故障类型，而无法识别更细维度的故障原因。

故障反馈

高并发场景下，相对于单个请求处理的时延，故障反馈过程非常缓慢。比如单个请求处理只需要几个毫秒，但是检测到请求超时，至少需要几秒时间。如果减少超时时间，检测就会变得很不准确，通常会由于系统调度延迟，让超时时间出现大范围的波动。而且请求超时会触发一些系统资源，比如HTTP连接的关闭和重建，引起更大范围的超时。再比如依赖于CPU、内存或者请求TPS的监控数据，一般是通过异步线程在后台周期性进行统计实现的，当统计数据反馈到服务治理策略的时候，相比较请求时延，已经过去很长时间了，这个时候再去实施治理策略，得到的反馈数据已经不足以支持治理策略的实施。

服务治理的一般原则

故障识别困难、故障反馈缓慢导致了在故障场景下，不能像处理正常功能逻辑一样，通过复杂的逻辑，比如转移故障、采集更多历史数据计算最优解等保障本次请求尽可能成功。也不能假设一个实际无法模拟验证的故障，然后针对这个故障进行保护。

服务治理策略需要结合大量的实践来进行验证，总结起来有几个非常核心的原则：

• 快速失败优先于保障本次请求成功。通过快速失败降低故障的影响时间，减少故障对于系统资源的占用，让系统能够快速恢复到正常的处理水平。
• 治理策略的逻辑应该采用无状态算法，不依赖于其他微服务或者中间件，只依赖于本服务的内部状态就能够实施，避免依赖于复杂的错误检测机制。这个原则使得服务治理的策略依赖于相对实时的故障数据，减少治理策略本身的处理时间，让治理策略的前提和结果变得更好预测。
• 治理策略的实施条件和结果必须可以通过模拟的方式进行验证。虽然故障识别是非常困难的，但是任何治理策略都需要假设他出现的场景是什么，这个场景发生的时候，故障表现是什么，依赖于故障场景、故障表现来执行治理策略，并且可以评估不同治理策略对同样的故障场景和故障表现得出的保护效果。