你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
支持可靠性的云设计模式
设计工作负载体系结构时,应使用可应对常见挑战的行业模式。 模式可以帮助你在工作负载中做出有意的权衡,并针对所需的结果进行优化。 它们还有助于缓解源自特定问题的风险,这些问题可能会影响安全性、性能、成本和操作。 如果不缓解,这些风险最终将导致可靠性问题。 这些模式以实际体验为后盾,专为云规模和运营模型而设计,本质上与供应商无关。 使用已知模式来标准化工作负载设计是卓越运营的一个组成部分。
许多设计模式直接支持一个或多个体系结构支柱。 支持可靠性支柱的设计模式优先考虑工作负载可用性、自我保留、恢复、数据和处理完整性以及控制故障。
可靠性设计模式
下表总结了支持可靠性目标的云设计模式。
模式 | 总结 |
---|---|
代表 | 通过卸载与网络通信相关的跨领域任务来封装和管理网络通信。 生成的帮助程序服务代表客户端启动通信。 此中介点提供了向网络通信添加可靠性模式(例如重试或缓冲)的机会。 |
用于前端的后端 | 通过创建特定于特定前端接口的单独服务,将工作负荷的服务层个性化。 由于这种分离,支持一个客户端的服务层中的故障可能不会影响另一个客户端访问的可用性。 当你以不同的方式对待各种客户端时,可以根据预期的客户端访问模式确定可靠性工作的优先级。 |
隔层 | 在组件之间引入有意和完整的分段,以隔离故障的爆炸半径。 此故障隔离策略尝试仅包含遇到问题的隔舱的故障,防止对其他隔舱造成影响。 |
缓存端 | 通过引入按需填充的缓存,优化对频繁读取数据的访问。 然后,缓存用于对相同数据的后续请求。 如果源数据存储暂时不可用,缓存会创建数据复制,并且以有限的方式可用于保留经常访问的数据的可用性。 此外,如果缓存出现故障,工作负载可以回退到源数据存储。 |
断路器 | 防止对故障或不可用依赖项的连续请求。 通过这样做,此模式可防止重载出错的依赖项。 还可以使用此模式在工作负载中触发正常降级。 断路器通常与自动恢复相结合,以提供自我保护和自我修复。 |
声明检查 | 将数据与消息流分开,从而提供一种单独检索与消息相关的数据的方法。 消息总线不提供专用数据存储中通常存在的可靠性和灾难恢复,因此将数据与消息分开可以提高基础数据的可靠性。 这种分离还允许在发生灾难后采用消息队列恢复方法。 |
补偿事务 | 通过反转以前应用的操作的影响,提供从故障中恢复的机制。 此模式通过使用补偿操作解决关键工作负载路径中的故障,这些操作可能涉及直接回滚数据更改、中断事务锁,甚至执行本机系统行为来扭转这种影响的过程。 |
竞争性使用者 | 应用分布式和并发处理,以高效处理队列中的项。 此模型通过将使用者视为副本来构建队列处理中的冗余,因此实例故障不会阻止其他使用者处理队列消息。 |
事件溯源 | 将状态更改视为一系列事件,并在不可变的仅追加日志中捕获这些事件。 当可靠的更改历史记录在复杂的业务流程中至关重要时,可以使用此模式。 如果需要恢复状态存储,它还有助于状态重建。 |
联合标识 | 将信任委托给工作负载外部的标识提供者,用于管理用户并为应用程序提供身份验证。 卸载用户管理和身份验证会将这些组件的可靠性转移到标识提供者,后者通常具有较高的 SLA。 此外,在工作负载灾难恢复期间,身份验证组件可能不需要作为工作负载恢复计划的一部分进行寻址。 |
网关聚合 | 通过在单个请求中聚合对多个后端服务的调用,简化了客户端与工作负载的交互。 此拓扑使你能够将暂时性故障处理从跨客户端的分布式实现转移到集中式实现。 |
网关卸载 | 在将请求转发到后端节点之前和之后,将请求处理卸载到网关设备。 将此责任卸载到网关可降低后端节点上应用程序代码的复杂性。 在某些情况下,卸载会将功能完全替换为平台提供的可靠功能。 |
网关路由 | 根据请求意向、业务逻辑和后端可用性,将传入的网络请求路由到各种后端系统。 网关路由使你能够仅将流量路由到系统中正常的节点。 |
地理节点 | 部署跨多个地理区域以主动-主动可用性模式运行的系统。 此模式使用数据复制来支持任何客户端可以连接到任何地理实例的理想。 它可以帮助工作负载承受一个或多个区域性服务中断。 |
运行状况终结点监视 | 提供一种通过公开专门为此目的设计的终结点来监视系统的运行状况或状态的方法。 可以使用此终结点来管理工作负荷的运行状况,以及警报和仪表板。 还可以将其用作自我修复修正的信号。 |
索引表 | 通过使客户端能够查找元数据,以便可以直接检索数据,从而优化分布式数据存储中的数据检索,而无需执行完整的数据存储扫描。 由于客户端通过查找过程指向其分片、分区或终结点,因此可以使用此模式促进数据访问的故障转移方法。 |
领导选择 | 建立分布式应用程序实例的 领导 。 领导者协调与实现目标相关的职责。 此模式通过可靠地重定向工作来减轻节点故障的影响。 当领导者发生故障时,它还通过共识算法实现故障转移。 |
管道和筛选器 | 将复杂的数据处理分解为一系列独立的阶段,以实现特定结果。 每个阶段的单一责任可实现集中注意力,并避免干扰混杂的数据处理。 |
优先级队列 | 确保优先级较高的项在优先级较低的项之前得到处理和完成。 根据业务优先级分隔项,使你能够将可靠性工作集中在最关键的工作上。 |
发布方/订阅方 | 通过将直接客户端到服务或客户端到服务的通信替换为通过中间消息中转站或事件总线的通信,分离体系结构的组件。 |
基于队列的负载调控 | 通过在队列中缓冲传入请求或任务,并让队列处理器以受控的速度处理它们,来控制传入请求或任务的级别。 此方法可将任务的到达与其处理分离,从而提供针对突然需求高峰的复原能力。 它还可以隔离队列处理中的故障,使其不会影响引入。 |
速率限制 | 控制客户端请求的速率,以减少限制错误,并避免出现无限制的错误重试情况。 当服务被设计为避免达到指定限制时,此策略通过确认与服务通信的限制和成本来保护客户端。 它的工作原理是控制在特定时间段内发送到服务的操作的数量和/或大小。 |
重试 | 通过以受控方式重试某些操作,解决可能是暂时性或间歇性的故障。 缓解分布式系统中的暂时性故障是提高工作负载复原能力的关键技术。 |
Saga 分布式事务 | 通过将工作分解为较小的独立事务序列来协调长时间运行且可能复杂的事务。 每个事务还必须具有补偿操作,以扭转执行中的失败并保持完整性。 由于跨多个分布式系统的整体事务通常是不可能的,因此此模式通过实现原子性和补偿来提供一致性和可靠性。 |
计划程序代理监督程序 | 基于系统中可观测到的因素,跨系统有效地分发和重新分发任务。 此模式使用运行状况指标来检测故障,并将任务重新路由到正常的代理,以减轻故障的影响。 |
顺序保护 | 维护并发消息传送入口,同时支持按定义的顺序进行处理。 此模式可以消除难以排查的争用条件、有争议的消息处理或其他解决方法,解决可能导致故障的错误排序的消息。 |
分片 | 将负载定向到特定的逻辑目标以处理特定请求,从而启用归置进行优化。 由于数据或处理与分片隔离,因此一个分片中的故障仍与该分片隔离。 |
Strangler Fig | 提供一种方法,用于系统地将正在运行的系统的组件替换为新组件,通常在系统迁移或现代化期间。 此模式的增量方法可帮助缓解转换期间的风险。 |
限制 | 对资源或组件的传入请求的速率或吞吐量施加限制。 可以设计限制以帮助防止可能导致故障的资源耗尽。 还可以将此模式用作正常降级计划中的控制机制。 |
后续步骤
查看支持其他 Azure Well-Architected Framework 支柱的云设计模式: