瓜田老梁:FA1# 微服务流控防护场景与应对措施

瓜田老梁

读完需要

4

分钟

速读仅需 2 分钟

老梁,GitChat&CSDN 专栏《RocketMQ 实战与进阶》联合作者、参与了《RocketMQ 技术内幕》审稿工作。

微服务成了互联网架构的标配模式,对微服务之间的调用的流量治理和管控就尤为重要。哪些场景需要流量防控,针对这些场景又有哪些应对措施。有没有一个通用的措施来降低风险呢?这篇文章咱就聊聊这个。

1

   

服务被过载调用

应对措施:针对服务提供方 D 配置流量防护规则,对进入服务 D 的流量进行控制,从而对服务 D 提供保护。触发流控时可以有多重策略,例如:快速失败、预热模式、排队等待、预热模式+排队等待。

快速失败:发生流控时直接抛出异常。

预热模式:发生流控时,流量缓慢增加的一种模式,效果如下图所示,流量 QPS 从 200 缓慢增加到 600。

排队等待:请求匀速通过,过多请求需要排队,此时排队有超时时间,超过排队时间抛出流控异常。效果如下图所示:请求 QPS 保持 1000 的匀速通过。

预热模式+排队等待:这种模式是预热和排队等待的叠加模式,请求以匀速的方式缓慢增加。如下图:请求从 0 缓慢增加到 500,匀速通过一段时间后,再增加到 1000。

2

   

服务慢调用或故障

下面的场景 A 调用 B、A 调用 C、A 调用 D,当服务 B 服务不稳定时,服务 A 调用服务 B 发生了慢调用或者大量异常错误。这种场景,如果不干预,可能影响到 A 调用 C 和 A 调用 D 的状况。

应对措施:A 调用 B 配置熔断降级规则,当服务 B 不稳定发生慢调用或者异常时,如果触发阈值,将服务 B 的调用熔断;从而保护了服务 A 调用 C、服务 A 调用 D 的正常情况。

熔断效果: 熔断的实现通常通过断路器实现,具体过程为:

  • 当满足慢调用比例、异常比例、异常数量阈值后,触发熔断(OPEN),在熔断时长内拒绝所有请求

  • 当熔断过了定义的熔断时长,状态由熔断(OPEN)变为探测(HALF_OPEN)

  • 接下来的一个请求不发生慢调用或者异常,熔断结束由探测状态(HALF_OPEN)变为(CLOSED)

  • 接下来的一个请求发生慢调用或者异常,继续熔断,由探测状态(HALF_OPEN)变为(OPEN)

3

   

服务资源被挤占

分布式链路中,如果某一条链路产生慢调用,对其他链路造成挤压。除了上面提到配置熔断降级外,可以通过线程并发控制来隔离。下图中有 3 条链路,其中链路 1 由于服务 E 的不稳定,产生了慢调用。

链路标号调用链
链路1服务A-->服务D#Method1-->服务E
链路2服务B-->服务D#Method2-->服务F
链路3服务C-->服务D#Method2-->服务G

链路 1 慢调用可能导致如下情况:

  • 链路 1 线程数增多对服务 D 资源造成挤压

  • 对服务 D 资源的过度挤压,链路 2 和链路 3 造成不稳定

  • 极端情况导致整个服务 D 不可用,严重时引发雪崩

应对措施:通过对服务 D 的 MethodA1、MethodA2 的线程数并发设置规则,超过阈值时将会触发阻断,不再向下游调用,避免不可用引发雪崩。

并发控制效果 :下图中设置了调用方的并发线程数为 10,通过每分钟的查询可以看出,线程数一直保持在 10。

4

   

数据过热挤占资源

热点数据,比如:大促时的热销产品、秒杀类产品等。如下图所示,如果不对热点商品下单流量进行管控,可能对其他商品造成挤压;影响整个商品下单体验。

应对措施:通过对热点参数测速,配置流控规则,超过阈值时触发流控。例如:通过对入参产品 ID 进行测速,超过设置的阈值时,触发流控,避免对其过度挤占资源。

5

   

通用防护分组措施

上面的现象中,无论是服务不稳定、还是被挤占、或者被过载调用。除了通过上述的防护措施外,可以对服务进行等级划分并分组。

如下图所示:服务 A 和服务 D 为核心服务、服务 B 和服务 C 为非核心服务。通过将服务 D 进行分组,分成了 1 组和 2 组。分组 1 只允许核心服务调用,分组 2 只允许非核心服务调用。

这样做的好处:将流量进行物理隔离,避免由于非核心业务流量对核心业务流量造成挤压、保护核心链路稳定性。

分组措施@1 通常可以更换注册中心路径实现,服务 A 和服务 D(分组 1)放在同一个注册中心路径(例如:soa-group1);服务 B、服务 C、服务 D(分组 2)放在另一个不同的注册中心路径(例如:soa-group2)。

分组措施@2 通过对分组的服务节点打标实现,例如:服务 D(分组 1)节点被打标为 group1,服务 D(分组 2)节点被打标为 group2。在服务消费方订阅节点时根据不同的分组筛选节点调用。

EOF

往期推荐

深入分布式缓存之EVCache探秘开局篇(文末赠书)

蚂蚁金服资深技术专家经国:云原生时代微服务的高可用架构设计

一文看懂高可用:异地多活

阿里高级技术专家至简: Service Mesh 在超大规模场景下的落地挑战

欧创新:深度解析DDD中台和微服务设计

神一样的CAP理论在微服务中是如何应用的?

程序人家:你的老板逼你上微服务了吗??

缓存,确实很香,却也很受伤!

微博技术专家陈波:百亿级访问量的应用如何做缓存架构设计

天弘基金首席架构师李鑫:微服务接口限流的算法及架构实现

已火 2 年,Service Mesh究竟给微服务带来了什么?

波波老师: 解决微服务的数据一致性分发问题?

为什么我不推荐你盲目追求微服务?迟早要吃亏!

DevOps是微服务的秘方

阿里高级技术专家邱小侠:微服务架构的理论基础 - 康威定律

导致微服务失败的 11 个原因

停!你不需要微服务

缓存穿透、缓存击穿和缓存雪崩实践(附源码)

可能是全网最通俗易懂的微服务架构改造解读

想要加入中生代架构群的小伙伴,请添加群合伙人大白的微信

申请备注(姓名+公司+技术方向)才能通过哦!

   END     
#架构师必备#

点分享点点赞点在看
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值