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

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
任务调度 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的工作原理,敬请期待哦。

相关文章
|
1月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
1月前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
203 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
1月前
|
运维 监控 持续交付
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
291 36
微服务架构解析:跨越传统架构的技术革命
|
1天前
|
测试技术 双11 开发者
一文分析架构思维之建模思维
软件里的要素不是凭空出现的,都是源于实际的业务。本文从软件设计本源到建模案例系统的介绍了作者对于建模的思维和思考。
|
30天前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
64 11
|
29天前
|
NoSQL 前端开发 测试技术
👀探秘微服务:从零开启网关 SSO 服务搭建之旅
单点登录(Single Sign-On,简称SSO)是一种认证机制,它允许用户只需一次登录就可以访问多个应用程序或系统。本文结合网关和SaToken快速搭建可用的Session管理服务。
96 8
|
25天前
|
机器学习/深度学习 存储 人工智能
基于AI的实时监控系统:技术架构与挑战分析
AI视频监控系统利用计算机视觉和深度学习技术,实现实时分析与智能识别,显著提升高风险场所如监狱的安全性。系统架构包括数据采集、预处理、行为分析、实时决策及数据存储层,涵盖高分辨率视频传输、图像增强、目标检测、异常行为识别等关键技术。面对算法优化、实时性和系统集成等挑战,通过数据增强、边缘计算和模块化设计等方法解决。未来,AI技术的进步将进一步提高监控系统的智能化水平和应对复杂安全挑战的能力。
|
2月前
|
弹性计算 持续交付 API
构建高效后端服务:微服务架构的深度解析与实践
在当今快速发展的软件行业中,构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用,通过具体案例分析,展示如何利用微服务架构解决传统单体应用面临的挑战,提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署(CI/CD)等方面进行全面剖析,旨在为读者提供一套实用的微服务实施指南。
|
1月前
|
设计模式 负载均衡 监控
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
76 8
|
1月前
|
弹性计算 Kubernetes API
构建高效后端服务:微服务架构的深度剖析与实践####
本文深入探讨了微服务架构的核心理念、设计原则及实现策略,旨在为开发者提供一套系统化的方法论,助力其构建灵活、可扩展且易于维护的后端服务体系。通过案例分析与实战经验分享,揭示了微服务在提升开发效率、优化资源利用及增强系统稳定性方面的关键作用。文章首先概述了微服务架构的基本概念,随后详细阐述了其在后端开发中的应用优势与面临的挑战,最后结合具体实例,展示了如何从零开始规划并实施一个基于微服务的后端项目。 ####