分布式系统架构3:服务容错

简介: 分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!

这是小卷对分布式系统架构学习的第3篇文章,虽然知道大家都不喜欢看纯技术文章,写了也没多少阅读量,但是个人要成长的话,还是需要往深一点的技术上去探索的

1.为什么需要容错

分布式系统的本质是不可靠的,一个大的服务集群中,程序可能崩溃、节点可能宕机、网络可能中断,这些“意外情况”其实全部都在“意料之中”。故障的发生是必然的,所以需要设计一套健壮的容错机制来应对这些问题。

容错策略,指的是“面对故障,我们该做些什么”;而容错设计模式,指的是“要实现某种容错策略,我们该如何去做”。下面介绍7种常见的容错策略。

2.七种容错策略

7种常见的容错策略:故障转移、快速失败、安全失败、沉默失败、故障恢复、并行调用和广播调用

故障转移Failover

概念:分布式服务中,服务会有多个副本。如果调用的服务器出现故障,系统不会直接返回失败,而是切换到其他服务副本上,保证返回调用成功的结果。

故障转移需要设置重试次数,并且需根据实际业务场景考虑是否设置故障转移。示例:

现在有Service A → Service B → Service C 这么一条调用链。假设 A 的超时阈值为 100ms,而 B 调用 C 需要 60ms,然后不幸失败了,这时候做故障转移其实已经没有太大意义了。因为即使B调用C故障转移成功了,调用耗时至少增加60ms,A已经超时了,这种故障转移对系统无利。

适用场景:读多写少的采集,如:电商商品查询;对成功率要求高的采集

快速失败Failfast

当业务场景不允许,或者服务是非幂等时,重复调用会产生脏数据,就不能用故障转移了,需要用到快速失败。

概念:服务在调用失败后,立即返回错误,不做任何重试

示例:支付场景中,调用银行扣款接口,返回结果是网络异常。这时候无法区分是否已扣款了,为避免重复扣款,只能服务抛出异常报错,不能重试

适用场景:高实时性场景、交易支付场景

缺点:调用方需有较高容错能力

安全失败Failsafe

服务也区分主路和旁路,旁路的特点是服务失败了也不影响核心业务。比如spring项目中的日志、Debug信息等。旁路逻辑不影响最终结果。因此,对这类逻辑的容错策略就是,即使旁路逻辑失败了,也当做正确返回。

概念:当服务调用失败时,忽略异常并返回一个默认的结果,确保系统继续运行。

适用场景:非核心业务场景,日志处理、监控采集

优点:最大化保证系统稳定性

示例:java中的try-catch,Dubbo中的failsafe策略

沉默失败Failsilent

概念:大量请求如果都等到超时才失败,可能将系统的线程、内存、网络资源耗尽,影响整个服务稳定性。对该场景的失败策略是:当请求失败后,默认服务提供者一定时间内无法提供服务了,不再向它分配流量,将错误隔离开来。

实际应用场景:分布式系统中,单点故障时,流量调度系统不再给该节点分配流量,每隔5分钟自动检查节点是否恢复。

故障恢复Failback

不是单独存在的,通常默认使用快速失败+故障恢复策略

概念:故障恢复是指在服务调用失败后,将失败的请求异步存储下来,存到数据库或消息队列中,并定时重试或补偿,直到调用成功。这种方式对业务具有一定的“追溯”能力。故障恢复也需有最大重试次数限制

适用场景:实时性要求不高,数据一致性要求高的场景。如:库存更新、订单状态同步

优点:提高系统最终一致性

缺点:系统需配合消息队列,实现复杂

小结:前面5种容错策略都是针对调用失败后如何进行弥补的,下面2种是调用之前如何提供成功率的

并行调用Forking

概念:同时调用多个服务节点,只要任意一个节点返回成功结果即认为调用成功。对于调用结果相同或相似的服务节点,这种方式可大幅提高调用成功率。

适用场景:多副本部署场景、调用耗时长且高可用要求的场景。如:数据库分片存储查询

优点:提供成功率,减少等待时间(取决于最先返回成功的节点)

缺点:增加系统开销

广播调用Broadcast

概念:请求发送给所有服务实例,并收集所有返回结果,要求所有请求全部成功才算成功。这种方式适用于需要对多个节点进行同步操作的场景

适用场景:刷新分布式缓存、配置同步

优点:所有节点都能执行操作

缺点:并行执行开销大

实现方式:Dubbo的broadcast策略支持广播调用

7种容错策略对比

容错策略 优点 缺点 应用场景
故障转移 系统自动处理,调用者对失败信息不可见 会增加调用时间,也会导致额外的资源开销 调用幂等服务,对调用时间不敏感的场景
快速失败 调用者有失败的处理完全控制,不依赖服务的幂等性 调用者必须正确处理失败逻辑,容易引起雪崩 调用非幂等的服务,超时阈值较低的场景
安全失败 不影响主逻辑 只适用于旁路调用 调用链中的旁路服务
沉默失败 控制错误不影响全局 出错的地方将有一段时间内不可用 频繁超时的服务
故障恢复 调用失败后自动重试,也不影响主逻辑 推荐用于旁路服务调用,重试任务可能堆积,重试仍然可能失败 调用链中的旁路服务,对实时性要求不高的主逻辑
并行调用 尽可能在最短时间内获得最高的成功率 额外消耗机器资源,大部分调用可能是无用功 资源充足且失效容忍度低的场景
广播调用 支持同时对批量的服务提供者发起调用 资源消耗大,失败概率高 只适用于批量操作的场景

面试题准备

如果一个业务系统需要调用第三方的5个接口,这5个接口中只要有3个接口返回成功了就认为成功,问如何设计并实现

周志明大佬的答复:

我看这题是个圈套呀,大多数的架构设计题目,固定答案往往都是不对的。因为做技术设计是为了解决实际问题,不能谈兵,所以方案要根据希望实现的目标而定:

如果目的是这项业务尽可能快速地完成,那就forking策略,5个一起调用,成功3个算过。

如果目的是这项业务尽可能少消耗资源,那就failfast策略,先对它们出错概率做个先验判断,排序后先调用最容易出错的,错够3次算失败,后面的不执行。

如果目的是这项业务尽可能高概率地完成,那就failover策略

相关文章
|
2月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
371 3
|
3月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
253 0
|
13天前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
6月前
|
人工智能 安全 Java
智慧工地源码,Java语言开发,微服务架构,支持分布式和集群部署,多端覆盖
智慧工地是“互联网+建筑工地”的创新模式,基于物联网、移动互联网、BIM、大数据、人工智能等技术,实现对施工现场人员、设备、材料、安全等环节的智能化管理。其解决方案涵盖数据大屏、移动APP和PC管理端,采用高性能Java微服务架构,支持分布式与集群部署,结合Redis、消息队列等技术确保系统稳定高效。通过大数据驱动决策、物联网实时监测预警及AI智能视频监控,消除数据孤岛,提升项目可控性与安全性。智慧工地提供专家级远程管理服务,助力施工质量和安全管理升级,同时依托可扩展平台、多端应用和丰富设备接口,满足多样化需求,推动建筑行业数字化转型。
205 5
|
3月前
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
138 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
5月前
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
1403 57
|
5月前
|
消息中间件 缓存 算法
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
244 0
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
|
7月前
|
消息中间件 人工智能 监控
文生图架构设计原来如此简单之分布式服务
想象一下,当成千上万的用户同时要求AI画图,如何公平高效地处理这些请求?文生图/图生图大模型的架构设计看似复杂,实则遵循简单而有效的原则:合理排队、分工明确、防患未然。
230 14
文生图架构设计原来如此简单之分布式服务
|
7月前
|
并行计算 PyTorch 算法框架/工具
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
本文探讨了如何通过技术手段混合使用AMD与NVIDIA GPU集群以支持PyTorch分布式训练。面对CUDA与ROCm框架互操作性不足的问题,文章提出利用UCC和UCX等统一通信框架实现高效数据传输,并在异构Kubernetes集群中部署任务。通过解决轻度与强度异构环境下的挑战,如计算能力不平衡、内存容量差异及通信性能优化,文章展示了如何无需重构代码即可充分利用异构硬件资源。尽管存在RDMA验证不足、通信性能次优等局限性,但该方案为最大化GPU资源利用率、降低供应商锁定提供了可行路径。源代码已公开,供读者参考实践。
482 3
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
|
10月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。

热门文章

最新文章