瓜田老梁

读完需要

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 慢调用可能导致如下情况：

• 链路 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
#架构师必备#点分享点点赞点在看