微服务架构 —— 服务雪崩与容错方案
导航
- 一、什么是服务雪崩
- 二、雪崩效应的三个核心原因
- 三、容错
- 四、业界常见容错思路
- 五、常见容错组件
一、什么是服务雪崩
服务雪崩 指的是微服务架构中，微服务各节点之间由于网络通信异常或微服务自身故障等问题，导致请求堆积、任务堆积，消耗和占用容器线程，并由此而影响其他正常业务流程以及其他微服务节点，局部故障扩散为整体故障的一种现象，严重时可能导致整个系统瘫痪，就行“雪崩”一样。
二、雪崩效应的三个核心原因
- 被上游服务压垮
tomcat 在处理请求时会分配线程资源，但这个资源是有限的，默认的 tomcat 线程数是 200，可以通过 server.tomcat.max-threads 参数设置。但如果上游服务在某一时刻发来大量的请求，一度超过当前节点可以处理的请求数量，就可能会导致节点故障，引发雪崩。常见的解决办法是限流。 - 被下游服务拖垮
由于下游服务的响应过慢，导致服务堆积，从而拖慢了当前节点的处理节奏，积小成多，造成雪崩。
常见的解决办法是增加超时机制、熔断、降级等。 - 外部环境影响
当前节点所处的服务器环境，如内存、cpu等，同样可能影响当前节点的处理速度。
三、容错
服务故障不可避免，但是决不能因为局部故障导致大面积的服务瘫痪，容错是为了通过某些手段尽可能的减小发生故障的概率，以及就算发生了故障也不至于扩散开来，目的是提高整体微服务架构的可用性，做到“雪落而不雪崩”。
上面提到的 限流、熔断、降级等，都是容错的常见措施。
四、业界常见容错思路
- 隔离
指的是在服务内部，对一些业务进行划分，尽量减少故障线程耗尽所有服务线程资源。
常见的隔离手段有：线程池隔离、信号量隔离。
- 超时
设置最大响应时间，避免线程资源占用过久。 - 限流
限制请求的数量，一旦达到阈值，就拒绝额外的请求进入服务，保护服务节点的正常、平稳的运行。 - 熔断
当下游服务因为访问压力过大而响应变慢或失败，上游服务为了保护系统整体可用性，可以暂时切断对下游服务的调用，即牺牲局部，保全整体。
熔断分为三种状态：关闭、开启、半熔断。关闭：服务没有故障时熔断器所处的状态，对调用方的调用无任何限制；开启：后续对该接口的调用不再经过网络，直接执行本地的 fallback 方法；半熔断：尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率，如果达到预期，进入熔断关闭状态，若未达预期，则重新进入开启状态。 - 降级
托底方案，如果微服务调用失败，如超时，就执行降级方案。
五、常见容错组件
Sentinel、Hystrix、Resilience4j
小灰灰
秒速五厘米
太过爱你忘了你带给我的痛
港控/mmm°
柔情只为你懂
还没有评论，来说两句吧...