12、架构-流量治理之服务容错

2024-06-08 22:52

本文主要是介绍12、架构-流量治理之服务容错,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

概述      

          容错性设计(Design for Failure)是微服务的另一个核心原 则,也是笔者书中反复强调的开发观念转变。不过,即使已经有一定 的心理准备,大多数首次将微服务架构引入实际生产系统的开发者, 在服务发现、网关路由等支持下,踏出了服务化的第一步以后,很可 能仍会经历一段阵痛期,随着拆分出的服务越来越多,随之而来会面 临以下两个问题的困扰。

  • 由于某一个服务的崩溃,导致所有用到这个服务的其他服务都 无法正常工作,一个点的错误经过层层传递,最终波及调用链上与此 有关的所有服务,这便是雪崩效应。如何防止雪崩效应便是微服务架 构容错性设计原则的具体实践,否则服务化程度越高,整个系统反而 越不稳定。
  • 服务虽然没有崩溃,但由于处理能力有限,面临超过预期的突 发请求时,大部分请求直至超时都无法完成处理。这种现象产生的后 果与交通堵塞类似,如果一开始没有得到及时的治理,后面就需要很 长时间才能使全部服务都恢复正常。

        本章我们将围绕以上两个问题,提出服务容错、流量控制等一系列解决方案。这些措施并不是孤立的,它们相互之间存在很多联系,其中许多功能必须与此前介绍过的服务注册中心、服务网关、负载均衡器配合才能实现。理清楚这些技术措施背后的逻辑链条,是了解它 们工作原理的捷径。

服务容错

        在现代分布式系统的构建中,服务容错设计是一个不可或缺的主题。Martin Fowler与James Lewis提出的“微服务的九个核心特征”是构建微服务系统的指导性原则,但不是技术规范,没有严格的约束力。在实际构建系统时,其中多数特征可能会有或多或少的妥协,比如分散治理、数据去中心化、轻量级通信机制、演进式设计,等等。但也有一些特征是不能妥协的,其中的典型就是今天我们讨论的主题:容错性设计。

        容错性设计不能妥协的原因在于分布式系统的不可靠性。一个大的服务集群中,程序可能崩溃、节点可能宕机、网络可能中断,这些“意外情况”其实全部都在“意料之中”。原本信息系统设计成分布式架构的主要动力之一就是为了提升系统的可用性,最低限度也必须保证将原有系统重构为分布式架构之后,可用性不下降才行。如果服务集群中出现任何一点差错都能让系统面临“千里之堤溃于蚁穴”的风险,那分布式恐怕就没有机会成为一种可用的系统架构形式了。

容错性设计的必要性

在一个复杂的分布式系统中,服务之间通过网络进行通信,而网络的不可靠性和服务本身的复杂性使得故障不可避免。常见的故障类型包括硬件故障、软件故障、网络故障和人为错误。这些故障如果没有有效的容错机制,将对系统的可用性和稳定性造成严重影响。

容错性设计的核心理念是“设计中包含对失败的预期和应对措施”,这有助于避免系统因单点故障而发生崩溃,从而提升整体系统的稳定性和可靠性。接下来,我们将详细探讨几种常见的容错策略和设计模式。

容错策略

  1. 故障转移(Failover): 故障转移是指当某个服务节点发生故障时,系统会自动切换到其他服务副本,以保证服务的连续性。实现这种策略需要使用负载均衡器或服务注册发现工具(如Consul、Eureka)。例如,当服务A所在的节点出现故障时,负载均衡器会将流量重定向到服务A的另一副本。这种机制保证了即使某个节点故障,用户的请求仍能被正常处理。然而,故障转移策略需要限制重试次数,以避免因频繁切换导致的系统不稳定。

  2. 快速失败(Failfast): 在某些情况下,服务不允许进行故障转移,因为故障转移可能会导致重复数据或其他问题。快速失败策略在检测到故障后立即返回错误,而不是进行重试,以避免进一步的问题。举例来说,在一个实时支付系统中,如果服务B发生故障,与其反复重试导致延迟增加,不如快速返回错误,让上游服务进行处理。

  3. 安全失败(Failsafe): 对于一些非关键服务或旁路逻辑,即使发生故障,也不会影响核心业务的正常运行。安全失败策略允许这些非关键服务在发生故障时返回默认值或零值,以保证系统的稳定性。例如,在一个推荐系统中,如果推荐服务出现问题,可以返回一个空列表,而不影响用户的购物流程。

  4. 沉默失败(Failsilent): 当某个服务出现大量超时时,系统会默认该服务在一定时间内无法提供服务,从而将其隔离,避免对系统其他部分造成影响。例如,如果服务C的响应时间显著增加,系统可以将其标记为不可用,暂时不再发出请求。

  5. 故障恢复(Failback): 在故障发生后,系统会自动尝试重试调用,并在后台异步处理这些请求,直到成功。故障恢复通常与快速失败结合使用。例如,在订单处理系统中,如果某个订单处理服务失败,系统可以将失败的订单放入队列中,并在后台进行重试,直到处理成功。

  6. 并行调用(Forking): 系统同时向多个服务副本发起调用,只要其中一个返回成功,就认为调用成功。这种策略增加了成功的概率和响应速度,适用于关键业务场景。例如,在支付系统中,可以同时向多个支付网关发起请求,哪个先返回成功就采用哪个的结果。

  7. 广播调用(Broadcast): 系统同时向多个服务副本发起调用,所有调用必须成功才认为此次调用成功。这种策略通常用于需要确保数据一致性的场景,如刷新分布式缓存。例如,在数据同步系统中,向所有节点广播更新指令,确保每个节点的数据都得到更新。

容错设计模式

  1. 断路器模式(Circuit Breaker): 断路器模式通过监控服务调用的成功和失败次数,当故障次数达到阈值时,将断路器状态切换为“OPEN”,直接返回失败,不再发出远程请求,从而避免因持续失败导致系统资源消耗和请求堆积。这种模式有三个状态:

    • 关闭(Closed):服务正常运行,所有请求正常通过。
    • 打开(Open):检测到连续多次失败,断路器打开,直接拒绝请求。
    • 半开(Half-Open):经过一段时间,断路器尝试部分请求,若成功则恢复正常状态,否则继续保持打开。

    例如,Netflix的Hystrix库实现了断路器模式,当某个服务的错误率超过设定阈值时,Hystrix会打开断路器,短时间内不再向该服务发起请求,从而保护系统不被单个服务的故障拖垮。

  2. 舱壁隔离模式(Bulkhead Isolation): 舱壁隔离模式通过将系统资源隔离成多个独立的部分,防止某一部分的故障影响整个系统。比如,可以为不同的服务分配独立的线程池、连接池等资源,确保某个服务的资源消耗不会影响其他服务。就像船只的舱壁一样,即使一个舱壁进水,也不会影响整艘船的浮力。

    例如,假设系统中有服务A和服务B,它们分别使用独立的线程池。如果服务A由于突发流量导致线程池耗尽,服务B仍然可以正常工作,因为它不受服务A的影响。

  3. 重试模式(Retry): 重试模式在请求失败后自动重试,增加请求成功的概率。可以在调用逻辑中实现重试机制,设置重试次数和间隔时间。例如,在一个文件上传系统中,如果上传失败,可以设置重试三次,每次间隔五秒,以增加上传成功的几率。

  4. 服务降级(Fallback): 服务降级策略在服务发生故障时提供降级逻辑,确保系统在某种程度上仍能提供服务。例如,当推荐服务发生故障时,可以返回缓存的推荐结果或默认推荐列表,而不是返回错误。通过这种方式,系统在部分功能失效的情况下仍能提供基本服务。

容错实现技术和工具

  1. Netflix Hystrix: Hystrix是Netflix开源的一个库,用于实现熔断、隔离、限流等容错机制。Hystrix能够帮助开发者迅速搭建容错体系。其主要功能包括:

    • 熔断器:实现断路器模式,防止故障扩散。
    • 隔离策略:通过独立的线程池隔离不同的服务,防止资源争用。
    • 请求缓存:在短时间内缓存请求结果,减少重复调用。
    • 监控与报警:提供丰富的监控指标和报警机制,帮助及时发现和处理故障。
  2. Sentinel: Sentinel是阿里巴巴开源的一个高可用防护组件,提供了丰富的流量控制、熔断降级、系统负载保护等功能。其主要功能包括:

    • 流量控制:通过设置流量阈值,防止系统过载。
    • 熔断降级:实现断路器和服务降级功能,保证系统稳定性。
    • 热点参数限流:对热点参数进行限流保护,避免单点压力过大。
    • 系统负载保护:根据系统负载自动调整限流策略,保证系统在高负载下的稳定性。
  3. Resilience4j: Resilience4j是一个轻量级、函数式的容错库,灵感来自于Hystrix,但设计上更为现代化,支持Java 8及以上版本。其主要功能包括:

    • 熔断器:实现断路器模式,防止故障扩散。
    • 重试:实现重试机制,增加请求成功的概率。
    • 限流:对请求进行限流保护,防止系统过载。
    • 缓存:在短时间内缓存请求结果,减少重复调用。

实际应用中的考虑

  1. 监控和报警: 实时监控系统的运行状态,及时发现和处理故障。可以使用Prometheus、Grafana等工具进行监控和报警设置。通过设置关键服务的性能指标,如响应时间、错误率等,可以实时监控系统的健康状况,并根据这些指标设置报警阈值,当指标超过阈值时触发报警,确保故障能够及时被发现和处理。

  2. 容量规划: 通过压力测试和容量评估,合理规划系统资源,确保系统在高并发和高负载下仍能稳定运行。例如,可以通过模拟高并发场景进行压力测试,测试系统的最大承载能力。根据压力测试结果,确定系统需要的资源配置,并设置自动扩展策略,根据系统负载自动调整资源配置。这样可以确保系统在高并发请求下仍能保持稳定和高效。

  3. 分布式事务管理: 在分布式系统中,事务管理是一个复杂的问题。可以使用TCC(Try-Confirm-Cancel)、Saga等模式来管理分布式事务,确保数据的一致性和可靠性。例如,TCC模式将事务拆分为尝试、确认、取消三个阶段,确保事务的一致性。Saga模式则将事务拆分为一系列独立的小事务,通过补偿操作来保证最终一致性。这些模式在需要跨多个服务的事务场景中非常有效,如订单处理、支付流程等。

结论

服务容错是保证分布式系统高可用性和可靠性的重要手段。通过合理使用故障转移、快速失败、安全失败、沉默失败、故障恢复、并行调用、广播调用等策略,以及断路器、舱壁隔离、重试、服务降级等设计模式,并结合实际场景进行优化和调整,可以有效提升系统的稳定性和容错能力。

在分布式系统中,服务容错不仅是技术上的挑战,更是设计理念上的转变。通过前面详述的各种策略和模式,我们可以看到,容错设计不仅仅是为了应对故障,更是为了构建一个具有高弹性和高可用性的系统。这种系统能够在面对各种不确定因素时,仍能保持稳定和可靠,最终为用户提供持续的优质服务。

这篇关于12、架构-流量治理之服务容错的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1043536

相关文章

mybatis的整体架构

mybatis的整体架构分为三层: 1.基础支持层 该层包括:数据源模块、事务管理模块、缓存模块、Binding模块、反射模块、类型转换模块、日志模块、资源加载模块、解析器模块 2.核心处理层 该层包括:配置解析、参数映射、SQL解析、SQL执行、结果集映射、插件 3.接口层 该层包括:SqlSession 基础支持层 该层保护mybatis的基础模块,它们为核心处理层提供了良好的支撑。

百度/小米/滴滴/京东,中台架构比较

小米中台建设实践 01 小米的三大中台建设:业务+数据+技术 业务中台--从业务说起 在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。

【区块链 + 人才服务】可信教育区块链治理系统 | FISCO BCOS应用案例

伴随着区块链技术的不断完善,其在教育信息化中的应用也在持续发展。利用区块链数据共识、不可篡改的特性, 将与教育相关的数据要素在区块链上进行存证确权,在确保数据可信的前提下,促进教育的公平、透明、开放,为教育教学质量提升赋能,实现教育数据的安全共享、高等教育体系的智慧治理。 可信教育区块链治理系统的顶层治理架构由教育部、高校、企业、学生等多方角色共同参与建设、维护,支撑教育资源共享、教学质量评估、

poj 2135 有流量限制的最小费用最大流

题意: 农场里有n块地,其中约翰的家在1号地,二n号地有个很大的仓库。 农场有M条道路(双向),道路i连接着ai号地和bi号地,长度为ci。 约翰希望按照从家里出发,经过若干块地后到达仓库,然后再返回家中的顺序带朋友参观。 如果要求往返不能经过同一条路两次,求参观路线总长度的最小值。 解析: 如果只考虑去或者回的情况,问题只不过是无向图中两点之间的最短路问题。 但是现在要去要回

【区块链 + 人才服务】区块链集成开发平台 | FISCO BCOS应用案例

随着区块链技术的快速发展,越来越多的企业开始将其应用于实际业务中。然而,区块链技术的专业性使得其集成开发成为一项挑战。针对此,广东中创智慧科技有限公司基于国产开源联盟链 FISCO BCOS 推出了区块链集成开发平台。该平台基于区块链技术,提供一套全面的区块链开发工具和开发环境,支持开发者快速开发和部署区块链应用。此外,该平台还可以提供一套全面的区块链开发教程和文档,帮助开发者快速上手区块链开发。

poj 3422 有流量限制的最小费用流 反用求最大 + 拆点

题意: 给一个n*n(50 * 50) 的数字迷宫,从左上点开始走,走到右下点。 每次只能往右移一格,或者往下移一格。 每个格子,第一次到达时可以获得格子对应的数字作为奖励,再次到达则没有奖励。 问走k次这个迷宫,最大能获得多少奖励。 解析: 拆点,拿样例来说明: 3 2 1 2 3 0 2 1 1 4 2 3*3的数字迷宫,走两次最大能获得多少奖励。 将每个点拆成两个

poj 2195 bfs+有流量限制的最小费用流

题意: 给一张n * m(100 * 100)的图,图中” . " 代表空地, “ M ” 代表人, “ H ” 代表家。 现在,要你安排每个人从他所在的地方移动到家里,每移动一格的消耗是1,求最小的消耗。 人可以移动到家的那一格但是不进去。 解析: 先用bfs搞出每个M与每个H的距离。 然后就是网络流的建图过程了,先抽象出源点s和汇点t。 令源点与每个人相连,容量为1,费用为

poj 3068 有流量限制的最小费用网络流

题意: m条有向边连接了n个仓库,每条边都有一定费用。 将两种危险品从0运到n-1,除了起点和终点外,危险品不能放在一起,也不能走相同的路径。 求最小的费用是多少。 解析: 抽象出一个源点s一个汇点t,源点与0相连,费用为0,容量为2。 汇点与n - 1相连,费用为0,容量为2。 每条边之间也相连,费用为每条边的费用,容量为1。 建图完毕之后,求一条流量为2的最小费用流就行了

数据治理框架-ISO数据治理标准

引言 "数据治理"并不是一个新的概念,国内外有很多组织专注于数据治理理论和实践的研究。目前国际上,主要的数据治理框架有ISO数据治理标准、GDI数据治理框架、DAMA数据治理管理框架等。 ISO数据治理标准 改标准阐述了数据治理的标准、基本原则和数据治理模型,是一套完整的数据治理方法论。 ISO/IEC 38505标准的数据治理方法论的核心内容如下: 数据治理的目标:促进组织高效、合理地

系统架构设计师: 信息安全技术

简简单单 Online zuozuo: 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo :本心、输入输出、结果 简简单单 Online zuozuo : 文章目录 系统架构设计师: 信息安全技术前言信息安全的基本要素:信息安全的范围:安全措施的目标:访问控制技术要素:访问控制包括:等保