服务线上治理

Posted key_3_feng

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了服务线上治理相关的知识,希望对你有一定的参考价值。

线上治理是根据量化分析的结果,通过相应的预案对线上服务的运行状况进行调整,保证线上服务正常运行,接下来讨论线上服务常见的预案,以及如何保证预案的自动触发和自动调整。

故障快速定位和止损的理想处理方式是将故障定位和预案执行打通,当出现故障时,能够判断出故障的大体类型以及对应的预案,并触发预案的自动执行。

当然实际的故障处理过程中有很多地方需要考虑,虽然并不是所有故障都能提前建立相应的预案,但我们可以根据历史故障和一些先验知识将故障进行归类,建立相应的预案。

另外,建立预案时应尽量方便执行和触发,如果不方便执行,很难短时间内处理故障,最关键的问题是判断预案触发的时机,以及当前是否应该执行预案。线上服务稳定性故障大体可以归类为如下原因。

  • 变更引起的故障

变更是稳定性故障的最主要来源,系统广义的变更源很多,最常见的服务变更一般包含应用变更、配置变更和数据变更。除了服务变更之外,环境和硬件的变化,比如网络带宽变化、机房链路变化等,也可以归为广义的变更范畴。

  • 流量和容量变化引起的故障

这类故障对应于之前稳定性保障中分析的输入流量突变,如果服务提前没有足够的应对机制,会导致一定的稳定性隐患。

  • 依赖故障

依赖服务故障会影响调用依赖服务的上游服务,依赖服务故障又分为强依赖服务故障和弱依赖服务故障,这两者会有相应的处理方式。

  • 机房、网络等硬件和环境故障

硬件和环境故障的特点是没有办法预测,随机性和偶然性因素很大,并且一旦发生往往是系统级别的问题,会产生很严重的后果。

  • 其他

比如ID生成器溢出导致的故障。

故障的场景化是指根据上述稳定性故障的大类,再细化出一些方便识别判断的场景,比如入口流量突增、接入层故障、强依赖服务故障、弱依赖服务故障等细分的场景。划分这些场景的目的是发生故障时,进一步识别故障的根因(不一定是最根本原因,而是从止损的角度进行归类)。因此可以对那些比较容易通过可观测性指标判断出故障的场景类型,并且方便制定相应的场景化预案的故障,进行场景化归类。

对于降级、限流和冗余切流这几类比较明确的场景,可以基于Metric进行故障判断,并且和预案自动打通,以依赖服务故障为例,可以根据Metric成功率指标同环比变化,判断依赖服务是否有异常,如果通过Metric发现当前确实有异常,先查询变更管理平台,依赖服务当前是否有相关的变更操作。

如果有变更,建议依赖服务接口人立即进行变更回滚操作;如果没有变更操作,再判断当前对依赖服务的调用是强依赖还是弱依赖,如果是弱依赖,可以启动自动降级预案对依赖服务进行降级,如果是强依赖,降级肯定不能解决问题,可以通过预先制定好的冗余切换预案,启动服务级、集群级或者机房级别的流量切换。

基于Metric的场景和预案打通,目标是朝着故障定位自动化和智能化的方向演进,但需要根据实际情况逐步推进,对于一些不太容易判断的场景,建议谨慎操作,避免可能的误判,同时要定期对预案进行演练,保障预案触发的有效性。

以上是关于服务线上治理的主要内容,如果未能解决你的问题,请参考以下文章

微服务引擎的线上流量治理最佳实践

数据治理的背景

Nginx惊群效应引起的系统高负载

转转测试环境的服务治理实践

微服务治理实践 | 金丝雀发布

微服务架构体系的深度治理