【可靠性架构】可靠性架构第2部分:云的弹性和可用性设计模式

简介: 本故事旨在回顾与云环境中的弹性和可用性相关的一些流行设计模式。本故事的参考来自以下链接,所有图片均由各自的内容所有者提供。

提到https://en.wikipedia.org/wiki/Software_design_pattern详细概述了什么是设计模式,并参考了几种软件设计模式。本故事旨在回顾与云环境中的弹性和可用性相关的一些流行设计模式。

本故事的参考来自以下链接,所有图片均由各自的内容所有者提供。

可用性模式

可用性表示系统运行和工作的时间。它可能会受到系统维护、软件更新、基础架构问题、恶意攻击、系统负载和与第三方提供商的依赖关系的影响。可用性通常通过SLA和9来衡量。例如,“五个9”意味着99.999%的可用性,这意味着系统在一年内可以停机约5分钟。检查https://uptime.is/查找特定SLA的可用性

运行状况终结点监视

在云中,应用程序可能会受到几个因素的影响,如延迟、提供商问题、攻击者和应用程序问题。有必要定期监视应用程序是否正常工作。

解决方案大纲

  • 创建运行状况检查终结点
  • 端点必须进行有用的健康检查,包括存储、数据库和第三方依赖关系等子系统
  • 使用状态代码内容返回应用程序可用性
  • 以适当的时间间隔监控终点,以及距离客户较近的地点的延迟
  • 保护端点以防止攻击

有关完整概述,请参阅Microsoft链接

下图描述了AWS特定实现中的相同模式。这解释了健康检查应该有多深,而不是前面的静态页面。

有关详细信息,请参阅链接。

Other references

基于队列的负载调配

重载/频繁请求可能会使服务过载,从而影响可用性。通过对此类请求进行排队并异步处理,将有助于提高系统的稳定性。

解决方案大纲

  • 在任务和服务之间引入队列
  • 任务放置在队列中
  • 服务以所需的速度处理任务。在一些高级实现中,服务可能会根据队列大小自动缩放。
  • 如果需要响应,服务必须提供适当的实现,但是,这种模式不适合低延迟响应需求

有关完整概述,请参阅链接

其他参考资料

节流

限制服务或其组件或客户端使用的资源数量,以便即使在极端负载期间,服务也能继续运行,满足SLA要求

解决方案大纲

  • 设置单个用户访问的限制,监控指标并在超过限制时拒绝
  • 禁用或降级不重要的服务,以便关键服务能够正常工作,例如,视频通话只能在带宽问题期间切换到音频
  • 确定某些用户的优先级,并使用负载均衡来满足高影响客户的需求

有关完整概述,请查看链接

其他参考资料

弹性模式

弹性是系统从故障中优雅地恢复的能力。检测故障并快速高效地恢复是关键。

隔板(Bulk Head)

隔离应用程序组件,使其中一个组件的故障不会影响其他组件。隔板表示船舶的分段隔板。如果一个隔板受损,水只会在该隔板中,从而避免船舶沉没

解决方案大纲

  • 将服务实例划分为多个组并单独分配资源,以便故障不会消耗此池之外的资源
  • 根据业务和技术需求定义分区,例如,高优先级客户可能获得更多资源
  • 利用Polly/Histrix等框架,并使用Containers等技术提供隔离。例如,容器可以为CPU/内存消耗设置硬限制,以便容器的故障不会耗尽资源。

有关完整概述,请参阅链接

其他资源

断路器

当一个服务被认为已经失败,并且如果它继续运行可能会对其他应用程序产生负面影响时,它应该抛出异常,并且可以稍后在问题似乎已修复时恢复,可以恢复该服务

解决方案大纲

下图显示了使用状态机实现断路器

有关完整概述,请查看链接

其他参考文献

补偿事务处理

在分布式系统中,强一致性并不总是最佳的。最终的一致性会产生更好的性能和组件集成。当发生故障时,必须撤消前面的步骤。

解决方案大纲

  • 补偿事务将记录工作流的所有步骤,并在出现故障时开始撤消操作

下图描述了一个具有顺序步骤的示例用例。

补偿事务不必撤消完全相同的顺序,可以执行并行调用。

有关详细概述,请查看链接

其他参考文献

领导人选举

协调多个类似实例执行的操作。例如,多个实例可能正在执行类似的任务,可能需要协调,也可能避免对共享资源的争用。在其他一些情况下,可能需要汇总几个类似实例的工作结果。

解决方案大纲

单个任务实例应被选为领导者。这将与其他从属实例协调操作。由于所有事例都是相似的,并且是同行的,因此必须有一个强有力的领导人选举过程

领导人选举过程可以使用以下几种策略

  • 选择排名最低的实例或进程ID
  • 获取Mutex-当领导者断开连接或失败时,应小心释放Mutex
  • 实现常见的领导人选举算法,如Bully或Ring

此外,利用任何第三方解决方案,如Zookeeper,避免开发复杂的内部解决方案

有关详细概述,请查看链接

其他参考文献

重试

通过重试失败的操作来启用应用程序处理瞬时故障,以提高应用程序的稳定性

解决方案大纲

各种方法包括

  • 如果故障被视为非瞬时故障且不太可能修复,则取消
  • 如果故障看似异常,则立即重试,并且立即重试可能会成功
  • 如果故障看起来是临时问题,并且可能在短时间间隔后修复,例如API速率限制问题,请在延迟后重试。

重试尝试应谨慎,不应使已加载的应用程序紧张。此外,请考虑要重试的操作的安全性(Idemptent)

有关完整参考,请查看链接

其他参考文献

调度程序代理主管

协调更大的操作。当事情失败时,尝试恢复,例如使用重试模式并成功,但如果系统无法恢复,则撤消工作,以使整个操作以一致的方式失败或成功。

解决方案大纲

解决方案涉及3个参与者

  • 调度器-安排工作流中各个步骤的执行并协调操作。调度器还记录每个步骤的状态。调度器与代理通信以执行步骤。调度器/代理通信通常使用队列/消息传递平台异步进行
  • 代理-通过一个步骤封装调用远程服务引用的逻辑。每个步骤可能使用不同的代理
  • 主管-监视调度程序执行的任务中的每个步骤。在发生故障时,它请求由代理执行或由调度程序协调的适当恢复

下图显示了一个典型的实现

有关完整参考,请查看链接

其他参考文献

AWS特定模式

以下部分描述了一些显示特定AWS实现的模式。其中一些比较简单,但值得一看。

多服务器模式

在这种方法中,您可以在负载平衡器后面配置其他服务器,以提高数据中心/可用性区域内的可用性

您需要注意共享数据和粘性会话。利用其他数据访问模式解决此类问题

有关详细概述,请查看链接

多数据中心模式

这扩展了多服务器模式,通过在多个数据中心/可用性区域中创建服务器来解决数据中心故障

数据共享问题仍然如前一节所述。

有关完整概述,请查看链接

浮动IP模式

在这种情况下,应用程序会为服务器分配一个浮动IP,在发生故障时,该IP可以重新分配给另一个工作服务器。虽然这个想法是原始的,并且依赖于弹性IP特性,但是可以扩展该模式以实现高级架构。

有关完整概述,请查看链接


Tags

本文:https://architect.pub/architecting-reliability-part-2-resiliency-and-availability-design-patterns-cloud

相关文章
|
设计模式 存储 前端开发
MVVM、MVC、MVP三种常见软件架构设计模式的区别
MVC、MVP 和 MVVM 是三种常见的软件架构设计模式,主要通过分离关注点的方式来组织代码结构,优化开发效率。
744 12
|
3月前
|
设计模式 SQL 人工智能
Python设计模式:从代码复用到系统架构的实践指南
本文以Python为实现语言,深入解析23种经典设计模式的核心思想与实战技巧。通过真实项目案例,展示设计模式在软件开发中的结构化思维价值,涵盖创建型、结构型、行为型三大类别,并结合Python动态语言特性,探讨模式的最佳应用场景与实现方式,帮助开发者写出更清晰、易维护的高质量代码。
110 1
|
3月前
|
设计模式 人工智能 算法
Python设计模式:从代码复用到系统架构的实践指南
本文探讨了电商系统中因支付方式扩展导致代码臃肿的问题,引出设计模式作为解决方案。通过工厂模式、策略模式、单例模式等经典设计,实现代码解耦与系统扩展性提升。结合Python语言特性,展示了模块化、装饰器、适配器等模式的实战应用,并延伸至AI时代的设计创新,帮助开发者构建高内聚、低耦合、易维护的软件系统。
277 0
|
7月前
|
设计模式 机器学习/深度学习 前端开发
Python 高级编程与实战:深入理解设计模式与软件架构
本文深入探讨了Python中的设计模式与软件架构,涵盖单例、工厂、观察者模式及MVC、微服务架构,并通过实战项目如插件系统和Web应用帮助读者掌握这些技术。文章提供了代码示例,便于理解和实践。最后推荐了进一步学习的资源,助力提升Python编程技能。
|
10月前
|
设计模式 存储 算法
分布式系统架构5:限流设计模式
本文是小卷关于分布式系统架构学习的第5篇,重点介绍限流器及4种常见的限流设计模式:流量计数器、滑动窗口、漏桶和令牌桶。限流旨在保护系统免受超额流量冲击,确保资源合理分配。流量计数器简单但存在边界问题;滑动窗口更精细地控制流量;漏桶平滑流量但配置复杂;令牌桶允许突发流量。此外,还简要介绍了分布式限流的概念及实现方式,强调了限流的代价与收益权衡。
401 12
|
10月前
|
设计模式 监控 Java
分布式系统架构4:容错设计模式
这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。
230 12
|
设计模式 Java 关系型数据库
【Java笔记+踩坑汇总】Java基础+JavaWeb+SSM+SpringBoot+SpringCloud+瑞吉外卖/谷粒商城/学成在线+设计模式+面试题汇总+性能调优/架构设计+源码解析
本文是“Java学习路线”专栏的导航文章,目标是为Java初学者和初中高级工程师提供一套完整的Java学习路线。
815 37
|
12月前
|
设计模式 API 持续交付
深入理解微服务架构:设计模式与实践
【10月更文挑战第19天】介绍了微服务架构的核心概念、设计模式及最佳实践。文章详细探讨了微服务的独立性、轻量级通信和业务能力,并介绍了聚合器、链式和发布/订阅等设计模式。同时,文章还分享了实施微服务的最佳实践,如定义清晰的服务边界、使用API网关和服务发现机制,以及面临的挑战和职业心得。
|
12月前
|
设计模式 测试技术 持续交付
架构视角下的NHibernate:设计模式与企业级应用考量
【10月更文挑战第13天】随着软件开发向更复杂、更大规模的应用转变,数据访问层的设计变得尤为重要。NHibernate作为一个成熟的对象关系映射(ORM)框架,为企业级.NET应用程序提供了强大的支持。本文旨在为有一定经验的开发者提供一个全面的指南,介绍如何在架构层面有效地使用NHibernate,并结合领域驱动设计(DDD)原则来构建既强大又易于维护的数据层。
121 2
|
设计模式 存储 运维
微服务架构中的服务发现与注册中心设计模式
在现代软件工程实践中,微服务架构已成为构建灵活、可扩展系统的首选方案。本文将深入探讨微服务架构中至关重要的服务发现与注册中心设计模式。我们将从服务发现的基本原理出发,逐步解析注册中心的工作机制,并以Eureka和Consul为例,对比分析不同实现的优劣。文章旨在为开发者提供一套清晰的指导原则,帮助他们在构建和维护微服务系统时做出更明智的技术选择。