文档

应用防护规则适用场景

更新时间:

微服务的稳定性一直是您非常关注的话题。随着业务从单体架构向分布式架构演进以及部署方式的变化,服务之间的依赖关系变得越来越复杂,业务系统也面临着巨大的高可用挑战。AHAS应用防护就是一款借助流量控制、熔断降级等模块,来提高应用高可用能力的产品。本文介绍各个应用防护规则以及适用的场景。

不稳定场景

在生产环境中您可能遇到过以下不稳定的情况:

  • 大促时瞬间洪峰流量使得系统超出最大负载、Load飙高、系统崩溃导致用户无法下单。
  • “黑马”热点商品击穿缓存、数据库被打垮、挤占正常流量。
  • 调用端被不稳定第三方服务拖垮、线程池被占满、调用堆积,导致整个调用链路卡死。
不稳定场景

这些不稳定的场景可能会导致严重后果,但很多时候开发者容易忽视这些与流量、依赖相关的高可用防护。AHAS应用防护功能就可以预防这些不稳定因素带来的影响,针对流量进行高可用的防护,从而保障服务“稳如磐石”。

核心场景

应用防护各规则说明和适用的核心场景如下表所示。

应用防护规则描述核心场景说明文档
流量控制规则通过AHAS配置QPS模式的流控规则,当每秒的请求量超过设定的阈值时,会自动拒绝多余的请求。适用于需要限制突发的流量,在尽可能处理请求的同时来保障服务不被击垮的场景。配置流控规则
集群流控规则控制某个服务调用整个集群的实时调用量,解决因流量不均导致总体限流效果不佳的问题。
  • 单机流量不均导致的单机限流效果不佳
  • 集群小流量流控
  • 有业务含义的流量控制(分钟小时级)
配置集群流控规则
隔离规则控制某些调用的并发数(即正在进行的数目),防止过多的慢调用挤占正常的调用。在调用第三方服务时,防止过多的慢调用挤占正常调用的资源,避免服务不可用。配置隔离规则
熔断规则对不稳定的弱依赖调用进行自动熔断降级,暂时切断不稳定调用,避免局部不稳定因素导致整体的雪崩。避免局部不稳定因素(某个慢调用、异常服务)导致整体的雪崩,例如切断某个RT高的第三方服务调用,或针对某个ID的慢SQL访问进行熔断。配置熔断规则
热点防护规则自动识别热点参数并控制每个热点值的访问频次或并发量,可以有效地防止过“热”的参数访问挤占正常的调用资源。适用于针对某些热点数据中访问频次最高的Top数据进行控制的场景,例如针对一段时间内最频繁购买的商品ID进行控制,防止突发热点商品击穿缓存而导致大量请求到数据库的情形。配置热点规则
系统自适应保护规则结合系统指标和服务容量,自适应动态调整流量。用作全局的兜底防护规则。自适应流控
自动重试规则在客户端的部分场景下为系统提供自动重试的能力,同时支持自定义重试策略。适用于服务偶现非致命性异常的场景(如偶现的超时)。配置自动重试规则

流量控制规则

场景说明

流量是随机、不可预测的,可能就在某一时间会出现流量洪峰,例如双十一零点的场景。然而系统的容量总是有限的,如果突如其来的流量超过了系统的承受能力,就可能会导致请求处理堆积、堆积的请求处理缓慢、CPU/Load飙高,最后导致系统崩溃。因此,您需要针对这种突发的流量来进行限制,在尽可能处理请求的同时来保障服务不被击垮,这就是流量控制。流量控制的场景是非常通用的,适用于脉冲流量类等场景。

流控规则说明

通常在Web入口或服务提供方(Service Provider)的场景下,需要保护服务提供方自身不被流量洪峰打垮。此时通常根据服务提供方的服务能力进行流量控制,或针对特定的服务调用方进行限制。您可以结合前期压测评估核心接口的承受能力,通过AHAS配置QPS模式的流控规则,当每秒的请求量超过设定的阈值时,会自动拒绝多余的请求。关于流控规则的更多信息,请参见配置流控规则

集群流控规则说明

同时AHAS也提供集群流控(分布式限流)的能力,可以控制某个服务调用整个集群的实时调用量,解决因流量不均导致总体限流效果不佳的问题。关于集群流控的更多信息,请参见配置集群流控规则

如果您的业务符合以下场景,建议结合集群流控来保障服务稳定性:

  • 单机流量不均:由于负载不均衡等原因导致每台机器的流量不均,此时使用单机流控可能会出现没有达到请求总量,某些机器就开始限流的情况。
  • 集群小流量流控:某些高可用防护场景下,需要将服务调用QPS限制到很小的量,此时平均到每台机器的QPS可能小于1,无法通过单机流控进行精确控制。例如限制总QPS为50,但节点数为100个,平均到每个节点QPS为0.5。
  • 有业务含义的流量控制:例如限制某个API每个用户每分钟调用不超过10次。

并发控制与熔断规则

场景说明

一个服务常常会调用别的模块,可能是另外一个远程服务、数据库,或者第三方API等。例如,支付的时候,可能需要远程调用银联提供的API;查询某个商品的价格,可能需要进行数据库查询。然而,这个被依赖服务的稳定性是不能保证的。如果依赖的服务出现了不稳定的情况,请求的响应时间变长,则调用服务的方法的响应时间也会变长,线程会产生堆积,最终可能耗尽业务自身的线程池,服务本身也变得不可用。

微服务的架构示例图如下:

架构图.png

现代微服务架构都是分布式的,由许多微服务组成。不同服务之间相互调用,组成复杂的调用链路。以上的问题在链路调用中会产生放大的效果。复杂链路上的某一环不稳定,就可能会层层级联,最终导致整个链路都不可用。

规则说明

AHAS提供以下能力避免慢调用等不稳定因素造成服务不可用:

  • 并发控制:作为一种轻量级隔离的手段,控制某些调用的并发数(即正在进行的数目),防止过多的慢调用挤占正常的调用。更多信息,请参见配置隔离规则
  • 熔断:对不稳定的弱依赖调用进行自动熔断降级,暂时切断不稳定调用,避免局部不稳定因素导致整体的雪崩。更多信息,请参见配置熔断规则

    AHAS熔断规则基于熔断器模式的思想,在服务出现不稳定因素(例如响应时间变长、错误率上升)的时候暂时切断服务的调用,等待一段时间再进行尝试。一方面防止给不稳定服务“雪上加霜”,另一方面保护服务的调用方不被拖垮。AHAS应用防护支持两种熔断策略:基于响应时间(慢调用比例)和基于错误(异常比例),可以有效地针对各种不稳定的场景进行防护。

    说明
    • 熔断器模式一般适用于弱依赖调用,即降级后不影响业务主流程,开发者需要设计好降级后的回退逻辑(fallback)和返回值。
    • 即使服务调用方引入了熔断降级机制,开发者还是需要在HTTP或RPC客户端配置请求超时时间,来做一个兜底的防护。

热点防护规则

场景说明

为了防止被大流量打垮,您通常会对核心接口配置限流规则,但有的场景下配置普通的流控规则是不够的。

例如大促峰值的时候,会有不少“热点”商品,这些热点商品的瞬时访问量非常高。通常您可以事先预测一波热点商品,并对这些商品信息进行缓存“预热”,以便在出现大量访问时可以快速返回而不会都经过数据库。但每次大促都会涌现出一些“黑马”商品,这些“黑马”商品是无法事先预测的,没有被预热。当这些“黑马”商品访问量激增时,大量的请求会击穿缓存,直接经过数据库,导致数据库访问缓慢,挤占正常商品请求的资源池,最后导致系统崩溃。

规则说明

此时,利用AHAS的热点参数流控能力,自动识别热点参数并控制每个热点值的访问频次或并发量,可以有效地防止过“热”的参数访问挤占正常的调用资源。更多信息,请参见配置热点规则

热点防护1.png

系统自适应保护规则

场景说明

当您无法事先准确评估某个接口的容量,甚至无法预知核心接口的流量特征(如是否有脉冲情况)时,靠事先配置的规则可能无法有效地保护当前服务节点。当某些情况下机器的Load和CPU usage等突然开始飚高,但您却无法快速确认原因,也来不及处理异常时,您其实需要做的是快速止损,先通过自动化的兜底防护手段,将濒临崩溃的微服务“拉”回来。

规则说明

针对这些情况,AHAS提供了一种系统自适应保护规则,结合系统指标和服务容量,自适应动态调整流量。AHAS自适应流控结合系统的Load、CPU使用率以及服务的入口QPS、响应时间和并发量等几个维度的监控指标,通过一定的流控策略,让系统的入口流量和系统的负载达到一个平衡,让系统尽可能运行在最大吞吐量,同时保证系统整体的稳定性。更多信息,请参见自适应流控

系统规则可以作为整个服务的一个兜底防护策略,保障服务运行,对CPU密集型的场景会有较好的效果。

自动重试规则

场景说明

分布式系统中调用关系通常会比较复杂,服务之间的调用可能会偶尔出现异常。这些异常有的是不可恢复的(如业务错误),有的则是可以恢复的(如偶发的超时)。当系统遇到一些非致命性的错误(如偶现的超时等)时,可以通过重试的方式来避免系统最终失败。

规则说明

AHAS的自动重试规则可以在客户端的部分场景下为系统提供自动重试的能力,同时支持自定义重试策略。更多信息,请参见配置自动重试规则

  • 本页导读 (1)
文档反馈