前言微服务已经成为互联网架构的标准配置模式，微服务间调用的流量管控显得尤为重要。哪些场景需要流量防控，这些场景有哪些应对措施。是否有降低风险的一般措施？让我们在这篇文章中谈谈这个。1、服务被重载调用当服务D的一个接口服务被上游服务重载调用时，如果服务D不被保护，可能会把服务D整体拖垮。在这种场景下，我们需要对服务D进行限流，以保护服务D不被整体淹没。对策：为服务提供者D配置流量保护规则，控制进入服务D的流量，保护服务D。触发流量控制时可以有多种策略，例如：快速失败、预热模式、队列等待、warm-up模式+队列等待。Failfast：发生流控时直接抛出异常。预热模式：当流量控制发生时，流量缓慢增加。效果如下图所示。流量QPS从200慢慢增加到600。排队等候：请求匀速通过。太多的请求需要排队。此时队列有超时时间，超过队列时间会抛出流控异常。效果如下图所示：请求QPS以1000匀速通过。预热模式+排队：该模式是预热和排队的叠加模式，请求匀速缓慢增加。如下图所示：request从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），在熔断时间内拒绝所有请求。当熔断超过定义的熔断Duration时，状态由熔断（OPEN）变为检测（HALF_OPEN）下一个请求不会引起慢调用或异常，熔断结束状态由检测（HALF_OPEN）变为（CLOSED）的nextrequest发生慢调用或异常，继续熔断，从检测状态（HALF_OPEN）到（OPEN）3.服务资源拥挤在分布式链路中。如果一个链接产生慢调用，它会挤压其他链接。除了上面提到的配置熔断降级，还可以通过线程并发控制来隔离。下图中有3条链路，其中链路1由于服务E不稳定导致调用慢，链路1调用慢可能导致以下情况：链路1线程数增加挤压了线程服务D的资源过度挤压服务D，链接2和3的资源导致极度不稳定，导致整个服务D不可用，严重时会触发雪崩。对策：通过对服务D的MethodA1和MethodA2的线程并发数设置规则，当超过阈值时，触发阻塞，不再进行下游调用，避免不可用造成的雪崩。并发控制的效果下图中调用者并发线程数设置为10，从每分钟查询可以看出，线程数一直保持在10。4.数据过热占用资源和热点数据，例如：大促期间的热销产品、闪杀产品等。如下图，如果不控制热门产品的订单流量，可能会挤压其他产品；影响整个产品订购体验。对策：通过测量热点参数速度，配置流量控制规则，超过阈值触发流量控制。例如：通过测量输入产品ID的速度，当超过设定的阈值时，触发流控，避免过度占用资源。5、一般保护分组措施上述现象中，服务是否不稳定、拥挤、过载调用。除了上述保护措施外，还可以对服务进行分类和分组。如下图所示：ServiceA和ServiceD是核心服务，ServiceB和ServiceC是非核心服务。通过对服务D进行分组，分为组1和组2，组1只允许核心服务调用，组2只允许非核心服务调用。这样做的好处是物理隔离流量，避免非核心业务流量对核心业务流量的挤压，保护核心链路的稳定性。分组措施@1通常可以通过替换注册表路径来实现。服务A和服务D（group1）放在同一个registry路径下（例如：soa-group1）；服务B、服务C和服务D（组2）被放置在不同的注册表路径中（例如：soa-group2）。分组措施@2是通过标记组的服务节点来实现的，例如：服务D（组1）节点标记为group1，服务D（组2）节点标记为group2。服务消费者订阅节点时，根据不同分组过滤节点调用。
