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