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

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

引言

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

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

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


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


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

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

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

相关文章
|
10月前
|
人工智能 API 数据安全/隐私保护
Apifox 与 Apipost 的 API 文档引擎对比:底层架构、性能与可扩展性分析
深入探索市场上两大主流API工具——Apifox和Apipost的文档能力时,发现了令人惊讶的差距。这不仅仅是功能多寡的问题,更关乎开发效率与团队协作的质变。
|
9月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
999 0
|
6月前
|
Cloud Native Serverless API
微服务架构实战指南:从单体应用到云原生的蜕变之路
🌟蒋星熠Jaxonic,代码为舟的星际旅人。深耕微服务架构,擅以DDD拆分服务、构建高可用通信与治理体系。分享从单体到云原生的实战经验,探索技术演进的无限可能。
微服务架构实战指南:从单体应用到云原生的蜕变之路
|
12月前
|
人工智能 自然语言处理 数据可视化
两大 智能体框架 Dify vs Langchain 的全面分析,该怎么选?资深架构师 做一个彻底的解密
两大 智能体框架 Dify vs Langchain 的全面分析,该怎么选?资深架构师 做一个彻底的解密
两大 智能体框架 Dify vs Langchain 的全面分析,该怎么选?资深架构师 做一个彻底的解密
|
7月前
|
Java API 开发工具
灵码产品演示:软件工程架构分析
本演示展示灵码对复杂软件项目的架构分析与文档生成能力。通过Qwen3模型,结合PlantUML,自动生成系统架构图、微服务时序图,并提取API接口文档,实现高效、智能的代码理解与文档输出。
445 5
|
7月前
|
存储 JSON 数据处理
ClkLog埋点与用户行为分析系统:架构升级与性能全面提升
随着越来越多企业在实际业务中使用 ClkLog,数据规模和分析需求也不断提升,部分用户日活已经超过10万,为了顺应这一趋势,ClkLog 秉持 “开放透明、持续演进”的理念,推出了迄今为止最重要的一次性能优化升级。新版本在大规模数据处理与复杂查询场景中,性能表现实现了跨越式提升。经过多轮研发与严格测试,新版本现已正式上线:在原有付费版 1.0 的基础上架构全面升级,并同步发布全新的 2.0 版本。为用户带来更强的性能与更广的适用场景。
|
11月前
|
机器学习/深度学习 人工智能 算法
大型多模态推理模型技术演进综述:从模块化架构到原生推理能力的综合分析
该研究系统梳理了大型多模态推理模型(LMRMs)的技术发展,从早期模块化架构到统一的语言中心框架,提出原生LMRMs(N-LMRMs)的前沿概念。论文划分三个技术演进阶段及一个前瞻性范式,深入探讨关键挑战与评估基准,为构建复杂动态环境中的稳健AI系统提供理论框架。未来方向聚焦全模态泛化、深度推理与智能体行为,推动跨模态融合与自主交互能力的发展。
875 13
大型多模态推理模型技术演进综述:从模块化架构到原生推理能力的综合分析
|
9月前
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
387 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
8月前
|
存储 前端开发 JavaScript
如何开发设备管理系统中的经验分析报表板块 ?(附架构图+流程图+代码参考)
设备管理系统(EMS)助力企业高效管理设备生命周期,涵盖采购、维护到报废全流程。本文详解经验分析报表模块设计与开发,涵盖动态看板、点检、巡检、维修、保养及库存统计功能,提供代码示例与架构设计建议,提升设备管理效率与决策水平。
下一篇
开通oss服务