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

本文涉及的产品
云原生网关 MSE Higress,422元/月
MSE Nacos 企业版免费试用,1600元额度,限量50份
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
简介: 在微服务体系架构中,由于拆解的服务数变多了,服务发生故障的地方也会相应的增加,因此如何保证服务架构健壮是一个值得深思的问题。微服务容错机制正是这样一种稳定性解决方案,可以理解微微服务架构的保险丝,通过它可以对业务平台形成一种有效的保护机制。在发生平台异常时候,容错机制是平台稳定运行的最后一道屏障。

引言

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

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

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


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


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

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

假设我们有客户端服务,需要分别调用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的工作原理,敬请期待哦。

目录
打赏
0
0
0
0
328
分享
相关文章
大型多模态推理模型技术演进综述:从模块化架构到原生推理能力的综合分析
该研究系统梳理了大型多模态推理模型(LMRMs)的技术发展,从早期模块化架构到统一的语言中心框架,提出原生LMRMs(N-LMRMs)的前沿概念。论文划分三个技术演进阶段及一个前瞻性范式,深入探讨关键挑战与评估基准,为构建复杂动态环境中的稳健AI系统提供理论框架。未来方向聚焦全模态泛化、深度推理与智能体行为,推动跨模态融合与自主交互能力的发展。
155 13
大型多模态推理模型技术演进综述:从模块化架构到原生推理能力的综合分析
一文详解:工业软件“低代码开发平台”技术架构研究与分析
本文围绕工业软件低代码开发平台的机遇与挑战,提出基于自动化引擎的技术架构,由工具链、引擎库、模型库、组件库、工业数据网关和应用门户组成。文章分析了其在快速开发、传统系统升级中的应用模式及价值,如缩短创新周期、降低试错成本、解决资源缺乏和提升创新可复制性,为我国工业软件产业发展提供参考和支持。
十大主流联邦学习框架:技术特性、架构分析与对比研究
联邦学习(FL)是保障数据隐私的分布式模型训练关键技术。业界开发了多种开源和商业框架,如TensorFlow Federated、PySyft、NVFlare、FATE、Flower等,支持模型训练、数据安全、通信协议等功能。这些框架在灵活性、易用性、安全性和扩展性方面各有特色,适用于不同应用场景。选择合适的框架需综合考虑开源与商业、数据分区支持、安全性、易用性和技术生态集成等因素。联邦学习已在医疗、金融等领域广泛应用,选择适配具体需求的框架对实现最优模型性能至关重要。
1297 79
十大主流联邦学习框架:技术特性、架构分析与对比研究
基于 Spring Cloud 的微服务架构分析
Spring Cloud 是一个基于 Spring Boot 的微服务框架,提供全套分布式系统解决方案。它整合了 Netflix、Zookeeper 等成熟技术,通过简化配置和开发流程,支持服务发现(Eureka)、负载均衡(Ribbon)、断路器(Hystrix)、API网关(Zuul)、配置管理(Config)等功能。此外,Spring Cloud 还兼容 Nacos、Consul、Etcd 等注册中心,满足不同场景需求。其核心组件如 Feign 和 Stream,进一步增强了服务调用与消息处理能力,为开发者提供了一站式微服务开发工具包。
110 0
文生图架构设计原来如此简单之分布式服务
想象一下,当成千上万的用户同时要求AI画图,如何公平高效地处理这些请求?文生图/图生图大模型的架构设计看似复杂,实则遵循简单而有效的原则:合理排队、分工明确、防患未然。
163 14
文生图架构设计原来如此简单之分布式服务
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
221 12
微服务——MongoDB实战演练——表结构分析
本文档来源于数据库articledb,展示了一张图片资源。图片宽度为1207像素,高度607像素,采用内联显示方式。内容涉及图像处理与样式设定,适用于文档或网页设计中多媒体元素的布局参考。图片来源为cdn.nlark.com,支持webp格式并附带水印处理。
53 1
微服务——MongoDB实战演练——表结构分析
湖仓分析|浙江霖梓基于 Doris + Paimon 打造实时/离线一体化湖仓架构
浙江霖梓早期基于 Apache Doris 进行整体架构与表结构的重构,并基于湖仓一体和查询加速展开深度探索与实践,打造了 Doris + Paimon 的实时/离线一体化湖仓架构,实现查询提速 30 倍、资源成本节省 67% 等显著成效。
湖仓分析|浙江霖梓基于 Doris + Paimon 打造实时/离线一体化湖仓架构
体育赛事即时比分 分析页面的开发技术架构与实现细节
本文基于“体育即时比分系统”开发经验总结,分享技术实现细节。系统通过后端(ThinkPHP)、前端(Vue.js)、移动端(Android/iOS)协同工作,解决实时比分更新、赔率同步及赛事分析展示等问题。前端采用 Vue.js 结合 WebSocket 实现数据推送,提升用户体验;后端提供 API 支持比赛数据调用;移动端分别使用 Java 和 Objective-C 实现跨平台功能。代码示例涵盖比赛分析页面、API 接口及移动端数据加载逻辑,为同类项目开发提供参考。
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问