您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center 汽车系统工程   模型库  
会员   
   
嵌入式软件架构-高级实践
12月11-12日 北京+线上
LLM大模型与智能体开发实战
12月18-19日 北京+线上
需求分析与管理
2026年1月22-23日 北京+线上
     
   
 订阅
微服务架构:弹性设计
 
作者:coder
  41   次浏览      9 次
 2025-11-27
 
编辑推荐:
本文主要介绍了微服务架构中如何通过容错、高可用、灾难恢复三大基石,以及断路器、重试、舱壁等具体模式和服务网格等基础设施,来构建一个能够预防、隔离故障并能快速自愈的弹性系统,希望对您的学习有所帮助。
本文来自于搬运工来架构,由Alice编辑、推荐。

微服务架构中的弹性

1. 关键概念

  • 容错 (Fault Tolerance)
    • 定义:系统即使在组件发生故障时也能继续正常运行的能力。
    • 目标:在分布式系统中,故障不可避免(硬件故障、数据库失败、网络中断、软件错误),容错的目标是在这些故障发生时仍能保持服务功能。
    • 策略:常见的策略是 将故障与系统其他部分隔离 。
    • 确保:通过实施容错,可以确保 单点故障不会导致整个系统崩溃 ,从而保护数据完整性和用户体验。
  • 高可用性 (High Availability - HA)
    • 定义:这个概念侧重于 确保服务的持续可访问性 。
    • 目标:使系统保持24/7运行,这对于电子商务平台或关键业务服务等不能承受停机时间的应用程序至关重要。
    • 策略:实现高可用性的一个关键策略是使用 可用区 (Availability Zones - AZs) 。这些是云区域内独立的地理位置,拥有独立的电源、冷却和网络。通过将服务分布在多个可用区和多个区域,即使一个可用区或区域出现问题,也能维持运营。
    • 与灾难恢复 (DR) 的区别:高可用性旨在 保持服务日常平稳运行,通常处理较小、局部的问题

  • 灾难恢复 (Disaster Recovery - DR 容灾)
    • 定义:涉及 从重大系统故障中恢复的策略 。
    • 重点:高可用性侧重于防止停机,而灾难恢复则关注 在发生重大问题时如何恢复 。
    • 涉及:这可能包括 地理冗余 ,即如果整个数据中心发生故障,您的系统可以从不同的位置运行。
    • 与高可用性 (HA) 的区别:灾难恢复处理 可能导致整个系统崩溃的更大、灾难性事件 。
    • 重要性:高可用性和灾难恢复都是弹性微服务架构的关键组成部分。

概念小结 :

2. 弹性技术与模式

  • 断路器模式 (Circuit Breaker Pattern)
  • 目的:帮助 防止级联故障 。
  • 工作原理:
    1. 当对产品服务的调用失败并 重试后再次失败 时,这会触发预定义的 阈值 ,断路器会跳闸(从关闭状态变为打开状态)。
    2. 断路器处于 打开状态 时,所有后续请求都会立即失败,而不会尝试调用故障服务,从而给予服务恢复时间。
    3. 经过一段 短暂的超时 (例如,使用指数退避逻辑)后,断路器会重置为 半开状态 ,允许少量请求尝试再次调用服务。
    4. 如果这些尝试成功,断路器会关闭,恢复正常操作;如果再次失败,断路器会再次打开,给予服务更多恢复时间。
  • 实施考量:何时跳闸?在特定时间内失败多少请求算作决策依据?如何量化失败?期望的服务响应时间 (SLA) 是多少?断路器何时可以再次关闭?跳闸后多久应该再次尝试?应该给服务多长时间来恢复?
  • 重试与超时机制 (Retry & Timeout Mechanisms)
    • 重试 (Retries)
      • 目的:处理分布式系统中常见的 瞬时故障 (如网络问题或高负载)。
      • 策略:当请求失败时,系统会尝试再次发送请求。应采用 抖动 (Jitter)  或 指数退避 (Exponential Backoff)  策略,即随机化或增加重试之间的等待时间(例如,等待1秒,然后2秒,然后4秒)。
      • 避免:频繁重试可能会增加目标服务的负载,导致进一步的性能下降。
      • 便利性:许多SDK提供对指数退避和抖动的支持。
    • 超时 (Timeouts)
      • 目的:每个请求都应有一个定义的超时周期,如果在此时间内未收到响应,则认为请求失败。这可以 防止系统无限期地挂起在无响应的服务上 。
      • 设置:通常设置为几毫秒到几秒。
      • 平衡:过短的超时可能导致不必要的失败和重试,而过长的超时会占用资源并降低整体系统性能。
      • 关键:找到重试和超时机制的适当平衡点,以显著提高系统对瞬时故障的弹性。
  • 舱壁模式 (Bulkhead Pattern)
    • 目的:解决一个服务中的问题导致系统范围故障,影响所有服务的问题。
    • 关键思想:为每个服务根据其预期负载 分配最大数量的线程 。这为每个服务创建了 隔离的资源池 。
    • 工作原理:例如,当支付请求进来时,它被分配到支付服务的线程池;订单跟踪请求则进入其自己的线程池。如果支付服务线程池已满,新的支付请求将被拒绝,但系统可以提供自定义错误响应,而 其他服务的请求仍能正常处理 ,不受支付服务问题的影响。
    • 比喻:这就像船只中的 水密隔舱 ,一个隔舱的损坏不会导致整艘船沉没。
    • 好处:通过隔离资源,可以防止一个服务的问题消耗所有可用资源并影响整个系统。这显著增强了微服务架构的弹性和稳定性。
  • 健康检查与自愈 (Health Checks & Self-Healing)
  • 健康检查 (Health Checks)
    • 定义:通常是特殊的 REST API端点 ,允许微服务 自查其状态和依赖项 。
    • 检查内容:可以评估数据库连接、系统属性、资源可用性,甚至其他依赖服务的状态。
    • 实施:在Java环境中,可以使用MicroProfile Health API,通过实现 HealthCheck 接口并添加 Liveness 或 Readiness 注解来创建自定义健康检查过程。
  • 自愈 (Self-Healing)
    • 触发:当服务未能通过健康检查时,可以触发自动自愈机制。
    • 机制:可能包括 重启失败的服务 、 将流量从不健康的实例重定向 ,或 启动新实例以替换失败的实例 。
    • 结合Kubernetes:可以使用liveness probes自动重启未通过健康检查的Pods,并使用readiness probes确保流量仅路由到健康的实例。
    • 好处:减少停机时间、保持高可用性,并最大限度地减少手动干预的需求。
    • 核心:在微服务架构中,故障是不可避免的,关键在于快速检测这些故障并自动响应,使系统能够自愈并保持整体功能。
  • 服务网格 (Service Mesh)
    • 概念:一个 软件层 ,负责处理服务与应用程序之间的所有通信。
    • 功能:管理服务间的连接,提供 监控、日志、跟踪和流量控制 等功能。
    • 特点:独立于每个服务的代码,使其能够跨网络边界和与多个服务管理系统协同工作。
    • 弹性提供:服务网格提供 基础设施层面的弹性 ,将关键弹性功能从单个服务卸载到网格本身。
    • 主要优势:
      • 高级流量管理 对请求路由和流量行为进行精细控制,可以使用智能负载均衡算法(如轮询或最少连接)优化请求分发。这确保了高可用性并防止了瓶颈。
      • 可观测性 提供全面的监控功能,可以深入了解服务的健康状况、性能和行为。这对快速发现和解决问题至关重要。
      • 模式实现 可以在基础设施层面实现之前讨论的弹性模式,如 断路器、重试和超时 ,而无需开发人员承担其实现负担。
      • 高级部署策略 支持金丝雀发布 (Canary Releases) 和A/B测试 (A/B Testing),从而可以控制新功能的发布,最大限度地降低风险。

弹性技术与模式小结:

3. 跨环境实现弹性

  • 利用可用区 (Availability Zones - AZs) 实现高可用
    • 定义:AZ是一个特定地理区域内一个或多个具有冗余电源、网络和连接的独立数据中心。
    • 特点:每个AZ都是隔离的,但通过低延迟链路与同一区域内的其他AZ连接。它们被设计为独立,以便一个AZ的故障不会影响其他AZ。
    • 策略:通过将服务分布在 一个区域内的多个可用区 ,可以创建一个能够抵御局部故障的强大系统。这种方法确保即使一个区域出现问题,您的服务也能在其他区域继续运行,从而保持操作的连续性。

  • 跨区域策略 (Cross-Region Strategies) 实现灾难恢复
    • 目的:应对可能影响整个区域的 大规模灾难 。
    • 涉及:在 地理遥远的区域 复制服务和数据。
    • 机制:必须有 自动化故障转移机制 ,以便在需要时将流量重定向到备份区域。
    • 成本考量:虽然最大弹性可能涉及在多个区域部署并实时复制数据,但这可能成本高昂。需要根据恢复时间目标 (RTO)、数据一致性需求和法规遵从性等因素来评估具体要求,然后设计一个在满足业务需求的同时优化资源利用和成本的解决方案。

4. 弹性设计最佳实践

  • 从一开始就为故障而设计 (Design for Failure from the Start)
    • 原则:假设故障必然发生,并创建能够承受和从故障中恢复的系统。
    • 关键点:
      • 假设故障会发生 。
      • 实施优雅降级 (Graceful Degradation)  以保持部分功能。
      • 隔离服务 以防止级联故障。
    • 应用技术:
      • 断路器模式: 阻止对故障服务的请求。
      • 舱壁模式: 隔离不同组件,确保一个组件失败时,其他组件仍能运行。
      • 超时和带有指数退避的重试机制: 有效管理瞬时问题。
    • 工具:Hystrix 或 Resilience4j 可以帮助实现这些模式。
  • 持续测试与混沌工程 (Continuous Testing & Chaos Engineering)
    • 目的:定期测试有助于识别漏洞,而 混沌工程 (Chaos Engineering)  模拟故障,以确保系统能够承受意外问题。
    • 重要性:通过纳入这些实践,可以显著增强微服务的弹性。

总结

彩蛋:

如果上面的概念不是很理解,可以用下面类比的说法来辅助加深理解。

想象一下微服务架构就像一座由许多独立房屋组成的大城市。如果一座房子(一个服务)着火了:

  • 容错 就像在每座房子里安装防火墙,确保火灾不会蔓延到旁边的房子。
  • 高可用性 就像城市里有多条道路通往每座房子,即使一条路(网络)堵塞,你仍然可以通过其他路到达。
  • 灾难恢复 则像城市在另一个地方有一个备用城市(地理冗余),如果整个城市发生大规模灾难,人们可以搬到备用城市继续生活和工作。
  • 断路器 就像家里的保险丝,当电器短路时,它会跳闸切断电源,防止火灾蔓延到整个电路。
  • 重试与超时 就像你打电话订餐,如果第一次没打通(瞬时故障),你会等一会儿再试(重试),但如果你一直打不通超过一定时间(超时),你就会放弃并尝试其他餐厅。
  • 舱壁模式 就像一艘船被分成了多个独立的防水隔舱。即使船体一个部分被水淹没,水也不会蔓延到其他隔舱,整艘船仍然可以浮在水面上,不会沉没。
  • 健康检查与自愈 就像城市里的智能监控系统和自动应急响应团队。当某个区域的公共设施出现问题时(健康检查),系统会自动检测到,并立即派遣团队去修复或替换(自愈),以确保城市功能不中断。
  • 服务网格 则像城市里的一套智能交通和公共服务管理系统。它不仅能智能地调度车辆(流量管理),还能实时监控交通状况(可观测性),甚至在发生交通堵塞时自动调整信号灯和分流(基础设施层面的弹性模式),让城市运行更顺畅、更可靠。

 

   
41   次浏览       9 次
相关文章

聊聊云原生和微服务架构
Serverless:微服务架构的终极模式
如何实现微服务架构下的分布式事务?
微服务下的数据架构设计
相关文档

微服务和云原生应用
微服务架构原理和设计方法
0到3000万用户微服务之旅
微服务在微信后台的架构实践
相关课程

微服务架构设计与实践
领域驱动+微服务架构设计
云计算、微服务与分布式架构
云平台与微服务架构设计

最新活动计划
基于模型的数据治理与中台 11-11[北京]
软件架构设计方法、案例实践 11-13[北京]
AI智能化软件测试方法与实践11-20[北京]
UML与面向对象分析设计 11-25[北京]
LLM大模型与智能体开发实战 11-13[北京]
配置管理方法、实践、工具 12-11[北京]
 
 
最新文章
云原生架构概述
K8S高可用集群架构实现
容器云管理之K8S集群概述
k8s-整体概述和架构
十分钟学会用docker部署微服务
最新课程
云计算、微服务与分布式架构
企业私有云原理与构建
基于Kubernetes的DevOps实践
云平台架构与应用(阿里云)
Docker部署被测系统与自动化框架实践
更多...   
成功案例
北京 云平台与微服务架构设计
通用公司GE Docker原理与实践培训
某军工研究单位 MDA(模型驱动架构)
知名消费金融公司 领域驱动设计
深圳某汽车企业 模型驱动的分析设计
更多...