微服务架构服务容错设计分析

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 在微服务体系架构中,由于拆解的服务数变多了,服务发生故障的地方也会相应的增加,因此如何保证服务架构健壮是一个值得深思的问题。微服务容错机制正是这样一种稳定性解决方案,可以理解微微服务架构的保险丝,通过它可以对业务平台形成一种有效的保护机制。在发生平台异常时候,容错机制是平台稳定运行的最后一道屏障。

引言

微服务体系架构中,由于拆解的服务数变多了,服务发生故障的地方也会相应的增加,因此如何保证服务架构健壮是一个值得深思的问题。微服务容错机制正是这样一种稳定性解决方案,可以理解微微服务架构的保险丝,通过它可以对业务平台形成一种有效的保护机制。在发生平台异常时候,容错机制是平台稳定运行的最后一道屏障。

微服务架构为什么需要容错机制

说起来可能有一些年头了,以前小时候家里面经常出现电压不稳电灯忽明忽暗,有时候甚至出现短路停电的情况。每次一片漆黑的时候,大人们最常说的一句话就是:哎,估计又是保险丝断了哦。这里的保险丝就是保护家中电路电器的一种手段,当发生短路情况时,通过熔断保险丝来保护家中电器不受电流过载的影响。


在微服务架构体系中的熔断降级正是起到保险丝作用的基础组件。我们在进行架构设计时,不仅需要满足业务要求,同时也需要面向失败进行设计,意思就是说当外部条件发生变化或者内部出现异常时,平台的架构能够将这种异常的影响降到最低,强大的容错能力是优秀架构的关键指标。


回到今天的主题容错机制,我们可以反过来想,如果没有如果没有熔断降级系统容错机制,整个系统平台在异常情况下,会发生怎样的系统反应,我们先看下以下几种场景。

场景一:服务节点异常影响上游服务调用方

假设我们有客户端服务,需要分别调用Service1集群的接口、Service2集群的接口以及Service3集群的接口来完成一项业务流程,如果Service3集群发生异常情况,服务都还在,但是可能由于出现fullGC、慢查询、业务异常等情况,客户端在调用Service3集群时出现timeout,不能在规定时间内进行服务响应。当调用请求不断发出时,此时Client中的工作线程将会被这些调用的time out阻塞住,当业务不断进行请求时,Client对应的工作线程会越来越多的被阻塞住,进而导致客户端不可用。

image.png

当此客户端不可用时,可能上层调用方也会由Client的不可用向上影响,导致上层调用方也出现异常,就像病毒一样一层一层的传导,异常影响被不断向上放大,最终导致整个平台不可用。

image.png

场景二:流量激增导致服务不可用,影响其他依赖该服务的服务异常

我们假设Service1集群可以承载6000QPS的流量,正常情况下上游三个服务的流量总和都小于这个阈值。但是当流量发生激增时,其中一个服务QPS就超过了10000QPS,超出了Service1集群的服务能力,因此造成了集群的异常出现响应异常的情况,此时Service2集群以及Service3集群由于依赖Service1集群的服务,同样会出现线程阻塞的情况,最终导致整个平台的异常。

image.png

因此基于以上分析,微服务架构中引入熔断降级组件是为了提升微服务架构整体的容错能力。主要避免以下三种场景对平台稳定性的影响。

1、单个服务集群节点出现异常故障,其影响范围可能被无限向上游服务放大;

2、由于使用了共同基础服务,基础服务出现异常时,多租户相互影响;

3、某个服务的瞬时流量突增,某个服务集群扛不住,影响整个平台稳定性;

如何破局

资源隔离

我们以现实生活中的船舱为例,实际的船舱格局大致如下所示,船舱底部并不是完全的一整个空心结构,而是通过格子进行区域隔离。为什么这么设计呢?主要还是为了一旦发生船舱漏水,只影响其中一个隔离区域,而不是整个船舱都灌满水,从而达到一定程度保护船体不会因为一处漏洞而沉没的目的。


那么借助于船舱隔离的思想,在我们的程序世界中,我们是不是也可以采用资源隔离的方式来保护我们的微服务架构呢?答案是肯定的,也的确是这么做的。

image.png

1、线程池隔离

我们可以通过线程池隔离的方式来实现资源的隔离,不同的请求使用相应的线程池来处理,即便出现请求资源time out的情况,最多影响当前线程池的资源,而不会影响整个服务的线程资源。类似船舱中的隔离区域。

image.png

2、信号量隔离

信号量主要是用来控制线程数的,规定好一些调用最大的并发量,超过指定的信号量后,可以将请求丢弃或者延时处理,防止线程的不断增长导致的服务异常。

image.png

熔断

所谓熔断,正如上文所说,它的作用就是想保险丝一样,在流量过大或者请求错误率过大的情况下,此时保险丝就熔断了,对应的业务链路断开,不再提供服务。当流量恢复正常或者错误降低后,熔断开关再进行闭合,之前的业务链路重新恢复。这是一种很好的保护后端微服务的一种方式。

在大促期间,平台需要用足够的机器去保证核心商业链路正常运转,对于退款、退货这种服务,则可以通过暂时熔断的方式不对外提供服务,当大促过了之后再进行恢复。

image.png

在熔断机制中,核心的内容就是断路器的设计,断路器设计主要有两方面一个是状态转换的设计,一个是如何根据阈值以统计数据来执行核心的断路功能。

降级

和熔断的场景有点蕾丝,当系统流量过多时,系统资源有限,平台处理不过来那么多的请求。此时就可以可将不是那么重要的功能模块进行降级处理,停止对外服务,这样可以释放出更多的资源供给核心功能的去用。如下所示,商品详情页中,商品服务中方商品列表才是最重要的服务,至于用户的积分以及用户的头像此时并不是核心业务,所以在系统能力有限的情况下,优先让商品服务对外提供服务,其他服务进行降级处理。

image.png

总结

本文主要对微服务架构中的容错机制进行了分析,从为什么要有容错机制到如何通过资源隔离、熔断以及降级等方式实现微服务容错保护进行了阐述。下一篇文章将带大家看看熔断降级组件Hystrix的工作原理,敬请期待哦。

相关文章
|
9天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
7天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
12天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
56 6
|
12天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
28 1
|
8天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
21 1
服务架构的演进:从单体到微服务的探索之旅
|
15天前
|
负载均衡 Dubbo 算法
集群容错架构设计
集群容错架构设计
25 1
集群容错架构设计
|
17天前
|
存储 SQL Apache
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
Apache Doris 是一个基于 MPP 架构的高性能实时分析数据库,以其极高的速度和易用性著称。它支持高并发点查询和复杂分析场景,适用于报表分析、即席查询、数据仓库和数据湖查询加速等。最新发布的 2.0.2 版本在性能、稳定性和多租户支持方面有显著提升。社区活跃,已广泛应用于电商、广告、用户行为分析等领域。
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
|
7天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
30 5
|
9天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
29 7
|
8天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
24 5