微服务之熔断、降级、限流

雪崩效应

在IO型服务中,假设服务A依赖服务B和服务C,而B服务和C服务有可能继续依赖其他的服务, 继续下去会使得调用链路过长。如果在A的链路上某个或几个被调用的子服务不可用或延迟较高,则会导致调用A服务的请求被堵住。

堵住的请求会消耗占用掉系统的线程、io等资源,当该类请求越来越多,占用的计算机资源越来越多的时候,会导致系统瓶颈出现,造成其他的请求同样不可用,最终导致业务系统崩溃,雪崩效应。

容断机制

当服务者无法正常为消费者提供服务时 ,如请求超时、后台服务无响应、后台服务异常等, 通过容断机制直接返回统一处理结果,并对下次请求进行同样处理,直到后台服务功能正常。

微服务的提供者可能是一个基础服务也能是一个聚合服务,当消费者的请求到来,如果服务中的一个或者几个无法正常工作(挂了),此时在不做任何处理的情况下,消费者只能等待,直到超时,在高负载场景下,此类问题可能会导致服务提供者的资源耗尽甚至整个系统崩溃。

限流机制

防止爆发式流量直接压到后台服务实例,造成资源耗尽、甚至应用崩溃

控制访问流量,通过指定的策略消减流量(如网络层面限制访问流量、后服务实例使用技术手段限制并发数量等),使得落到后台服务实例的请求在能承受的范围内。高并发是常常讨论的话题,如何限流,以及服务的实例能承受的范围是多大,什么情况下需要增加服务实例,调整资源,都需要结合实际进行严格的测试。

这样一个场景,provider是一个核心服务,给N个consumer提供服务,突然某个consumer抽风,流量飙升,占用了provider大部分机器时间,导致其他可能更重要的consumer不能被正常服务。

所以,provider端,需要根据consumer的重要程度,以及平时的QPS大小,来给每个consumer设置一个流量上线,同一时间内只会给A consumer提供N个线程支持,超过限制则等待或者直接拒绝。

常见的限流算法有:令牌桶、漏桶。计数器也可以进行粗暴限流实现。

降级机制

当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核心流程的性能时,仍然需要保证服务还是可用的,即使是有损服务。

弃卒保帅,最终目的是保证核心服务可用,即使是有损的。但是核心服务肯定是无法舍弃的,舍弃也就意味着应用系统无法正常工作。只能是一种保障或者拯救措施。
 

降级和熔断的区别

  1. 触发原因不太一样,服务熔断一般是某个服务(下游服务)故障引起,而服务降级一般是从整体负荷考虑;
  2. 管理目标的层次不太一样,熔断其实是一个框架级的处理,每个微服务都需要(无层级之分),而降级一般需要对业务有层级之分(比如降级一般是从最外围服务开始)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值