服务降级的快速发现与三方告警

WhiteJunior

已于 2024-02-01 17:47:24 修改

阅读量726

点赞数 28

分类专栏：云计算文章标签：运维数据库云原生监控

于 2024-02-01 17:45:28 首次发布

本文链接：https://blog.csdn.net/lym940928/article/details/135966076

版权

云计算专栏收录该内容

23 篇文章 0 订阅

订阅专栏

一、熔断与降级

1、降级

基本概念
- 服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路） 错误处理信息。
- 虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。
出现原因
- 服务器的资源是有限的，而请求是无限的。在用户使用即并发高峰期，会影响整体服务的性能，严重的话会导致宕机，以至于某些重要服务不可用。故高峰期为了保证核心功能服务的可用性，就需要对某些服务降级处理，可以理解为舍小保大。
需要考虑的问题
- 区分哪些为核心业务、哪些为非核心业务；
- 降级的具体策略是什么（用户侧感知）；
- 自动降级还是手动降级；

2、熔断

基本概念
- 应对雪崩效应的链路自我保护机制。可看作降级的特殊情况，有时也称熔断为过载保护。
- 服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。
出现原因
- 微服务之间的数据交互一般通过远程调用来完成的。此时对于调用链：A -> B -> C。如果服务C的调用响应时间过长或者服务C不可用，随着时间的增长，对服务C的调用也越来越多，然后服务C崩溃了，但是链路调用还在，对服务B的调用也在持续增多，然后服务B整体崩溃，随之A也崩溃，从而造成导致雪崩效应。
- 服务熔断是应对雪崩效应的一种微服务链路保护机制：
  - 当调用链路的某个微服务不可用或者响应时间太长时，会进行服务熔断，不再有该节点微服务的调用，快速返回错误的响应信息。
  - 当检测到该节点微服务调用响应正常后，恢复调用链路。
需要考虑的问题
- 如何在即将熔断时触发告警、避免实际熔断；
- 熔断后依赖对象如何快速回复；
- 熔断后如何快速感知熔断依赖对象已恢复；

3、异同点

相同点：
- 目标一致：都是从可用性与可靠性出发，避免系统崩溃；
- 用户体验：最终用户感知到的都是某些功能暂时不可用；
不同点：
- 触发原因：降级是从整体负载考虑，熔断是由链路上的某个服务引起的；
- 管理目标层次：降级是业务层级处理，熔断时框架层次处理；

简而言之：

限流：限制并发的请求访问量，超过阈值则拒绝；
降级：服务分优先级，牺牲非核心服务（不可用），保证核心服务稳定；从整体负荷考虑；
熔断：依赖的下游服务故障触发熔断，避免引发本系统崩溃；系统自动执行和恢复；

二、降级详细说明

开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。

对于降级而言，当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，则需要执行手动或自动降级，其核心目的就是保证核心服务可用，即使是有损的。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级，并给出对应的降级预案：

自动开关降级：
- 根据当前系统整体负载、资源使用、SLA等指标达成情况等，实行自动降级；
人工开关降级：
- 人为发现了现网存在相关问题（数据库连接池打满、慢查询增长过快、网络异常波动等），手动处理（手动杀掉进程、改同步为异步等）实现降级；
超时降级：
- 当访问的数据库/http服务/远程调用响应慢或者长时间响应慢，且该服务不是核心服务的话可以在超时后自动降级；
- 果是调用别人的远程服务，和对方定义一个服务响应最大时间，如果超时了则自动降级;
统计失败次数降级：
- 有时候依赖一些不稳定的API，比如调用外部机票服务，当失败调用次数达到一定阀值自动降级；
- 而后，通过异步线程去探测服务是否恢复了，则取消降级；
故障降级：
- 比如要调用的远程服务挂掉了（网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常），则可以直接降级；
- 降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货）、兜底数据（比如广告挂了，返回提前准备好的一些静态页面）、缓存（比如认证接口挂了、使用已缓存的token）；
限流降级：
- 当访问量太大时，如果不做限流服务很容易被打挂。一般而言我们会对OpenAPI做访问量限制，达到限流阀值，后续请求会被降级；
- 降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）；

三、降级的发现与告警

由上面的说明我们了解，降级是服务可靠性保护的一种方式，通过降低业务功能或规格，避免流量过载或局部故障场景下造成服务整体不可用、从而影响核心特性。

但是我们也明白，本身降级是有损的，会对被降级服务的使用方造成影响。因此，当服务自身执行相关降级动作后，我们需要快速发现、并告警通知到被影响服务，避免降级给第三方服务造成影响。

这里，我们主要针对接口访问层面的降级操作，通过标准化日志打印、写入日志流的方法（利用日志组件自动实现），实现基于日志侧感知能力的降级发现与快速告警。

日志格式设计参考：

{
	"traceId": # 接口访问请求自动生成的追踪id
	"nenvId": # 调用方服务CMDB服务环境信息，是受到降级影响的服务
	"userId": # 调用方服务用户id信息
	"fallBackService": # 降级服务信息
	"fallBackFunction": # 降级函数信息
	"path": # 访问接口uri（不含参数）
	"currentTime": # 时间戳
	"msg": # 降级服务自定义降级信息
}