玩转Service Mesh微服务熔断、限流骚操作

在微服务架构中,随着服务调用链路变长,为了防止出现级联雪崩,在微服务治理体系中,熔断、限流作为服务自我保护的重要机制,是确保微服务架构稳定运行的关键手段之一。

那么什么是熔断、限流?在传统Spring Cloud微服务、以及新一代Service Mesh微服务架构中,它们分别又是怎么实现的?本文将对此进行阐述!

服务熔断、限流概述

先理解下熔断、限流的基本概念以及它们的应用场景。说起熔断这个词,大家印象深刻的可能是股市交易熔断、或者电路保险丝断开这样的场景;而微服务中的熔断本质上和这些场景中所描述的理念是一致的。都是为了在极端情况下,保证系统正常运行而设计的一种自我保护机制。

熔断的基本逻辑就是隔离故障。在微服务架构盛行的今天,服务之间的调用链路相比单体应用时代变得更长了,服务化拆分带来系统整体能力提升的同时,也增加了服务级联故障出现的概率。例如调用链路A->B->C->D,如果服务D出现问题,那么链路上的A、B、C都可能会出现问题,这一点也很好理解,因为出现故障的服务D,必然会在某个时间段内阻塞C->D的调用请求,并最终蔓延至整个链路。而服务连接资源又是有限的,这种增加的调用耗时,会逐步消耗掉整个链路中所有服务的可用线程资源,从而成为压垮整个微服务体系的幕后黑手。

而为了防止故障范围的扩大,就需要对故障服务D进行隔离,隔离的方式就是服务C在感知到对D的调用频繁出现故障(超时或错误)后,主动断掉对D的连接,直接返回失败调用结果。以此类推,如果微服务中的所有链路都设置这样的熔断机制,那么就能逐级实现链路的分级保护效果。

熔断机制虽然解决不了故障,但却能在故障发生时尽量保全非故障链路上的服务接口能被正常访问,从而将故障范围控制在局部。当然被熔断的服务也不会一直处于熔断状态,在熔断机制的设计中还要考虑故障恢复处理机制。

说完熔断,再来说说限流。熔断的主要目的是隔离故障,而引起故障的原因除了系统本身的问题外,还有一种可能就是请求量达到了系统处理能力的极限,后续新进入的请求会持续加重服务负载,最终导致资源耗尽,从而引起系统级联故障、导致雪崩。而限流的目的就是拒绝多余流量、保证服务整体负载始终处于合理水平。

从限流范围上看,微服务体系中的每个服务都可以根据自身情况设置合理的限流规则,例如调用链路“A->B->C->D”,B服务的承受力是1000QPS,如果超过该阀值,那么超出的请求就会被拒绝,但这也容易引起A对B的熔断,所以对于微服务设置限流规则的设置最好还是根据压测结果确定。

在实际场景中,对单个节点的微服务分别设置限流,虽然从逻辑上没啥毛病,但实际操作起来却并不容易,这主要是因为限流规则分散不好统一控制,另外对于单节点阀值的评估,在全链路环境下并不能得出1+1=2”的结果。所以,一般做法是根据全链路压测结果,在服务网关统一进行集群级别的限流处理。

接下来将分别介绍在Spring Cloud传统微服务体系,以及新一代Service Mesh微服务体系中,熔断、限流的基本实现原理,并重点演示基于Istio的微服务熔断、限流逻辑具体实践!

Spring Cloud微服务对熔断/限流的处理


说起Spring Cloud微服务中的熔断、限流,最先想到的肯定是Hystrix、Sentinel这样的技术组件。关于这两种著名的熔断、限流组件,在笔者早先的文章<<Spring Cloud中Hystrix、Ribbon及Feign的熔断关系是什么?>>以及<<Spring Cloud微服务Sentinel+Apollo限流、熔断实战>>中都曾详细介绍过,细节就不再赘述,感兴趣的朋友可以翻阅下。这里只从微服务架构的宏观视角,来对比分析下其与服务网格(Service Mesh)在架构上的区别。

从本质上说Hystrix与Sentinel并无实质差别,它们都是以SDK的形式附着在具体微服务进程之上的、实现了熔断/限流功能的本地工具包。具体示意图如下:

在Spring Cloud微服务中,Hystrix、Sentinel等熔断、限流组件通过嵌入微服务进程,统计微服务一段时期内的入口流量及依赖服务的错误调用次数、并根据组件的所提供功能及规则配置,来决定是否触发限流或熔断降级逻辑。这样的过程完全是附着在微服务进程本身完成的,虽然限流/熔断组件本身也提供了线程池隔离之类资源隔离手段,但从服务治理的角度来看,这样的方式显然还是侵入了业务、占用了业务系统资源;并且分散于应用的规则配置,也不利于微服务体系的整体管控。

Service Mesh微服务熔断/限流实现

前面简单概述了Spring Cloud微服务体系中实现熔断、限流机制的基本框架及存在的弊端。接下来将具体分析下同样的逻辑在Service Mesh微服务架构中是如何实现的?

关于Service Mesh微服务架构如果你还比较陌生,可以先通过笔者之前的文章<

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值