通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

支持性能效率的体系结构设计模式

设计工作负荷体系结构时，应使用行业模式来解决常见挑战。 模式有助于在工作负载中进行有意权衡，并针对所需结果进行优化。 它们还可以帮助缓解源自特定问题的风险，这些问题可能会影响可靠性、安全性、成本和作。 如果未缓解，风险最终将导致性能低效。 这些模式由实际体验提供支持，专为云规模和运营模型而设计，本质上与供应商无关。 将已知模式用作标准化工作负荷设计的方法，是卓越运营的一部分。

许多设计模式直接支持一个或多个体系结构支柱。 支持性能效率支柱的设计模式解决了可伸缩性、性能优化、任务优先级和瓶颈删除问题。

下表总结了支持性能效率目标的体系结构设计模式。

图案 概要
异步请求-回复 通过将不需要即时答案的进程的请求和回复阶段分离，从而提高系统的响应能力和可伸缩性。 通过使用异步模式，可以在服务器端最大化并发。 可以使用此模式将工作安排为容量允许完成的工作。
前端的后端 通过创建特定于特定前端接口的单独服务来个性化工作负荷的服务层。 这种分离使你能够以共享服务层可能不可能的方式进行优化。 以不同的方式处理单个客户端时，可以针对特定客户端的约束和功能优化性能。
舱 壁 引入组件之间的分段，以隔离故障的爆破半径。 此设计使每个大容量头能够单独缩放，以满足封装在大容量头中的任务的需求。
Cache-Aside 通过引入按需填充的缓存来优化对频繁读取数据的访问。 然后，对相同数据的后续请求使用缓存。 此模式对于不经常更改且可以容忍一定数量的过时的读取密集型数据特别有用。 此实现的目标是通过将此类数据卸载到缓存而不是从其数据存储中溯源，在系统整体中提供更好的性能。
编舞 使用分散式事件驱动的通信协调工作负荷中自主分布式组件的行为。 当集中式业务流程拓扑中出现性能瓶颈时，此模式可以提供替代方法。
断路器 防止对故障或不可用依赖项的持续请求。 重试错误方法可能会导致依赖项恢复期间资源使用率过高，并且还可以在尝试恢复的依赖项上重载性能。
声明检查 将数据与消息流分开，提供一种方法来单独检索与消息相关的数据。 当系统处理大型数据有效负载时，此模式可提高消息发布者、订阅者和消息总线本身的效率和性能。 它的工作原理是减小消息的大小，并确保使用者仅在必要时和适时检索有效负载数据。
竞争使用者 应用分布式和并发处理，以有效处理队列中的项。 此模型支持跨所有使用者节点分配负载，以及基于队列深度的动态缩放。
计算资源合并 通过增加密度优化和合并计算资源。 此模式结合了共享基础结构上工作负荷的多个应用程序或组件。 这种整合通过使用备用节点容量来最大程度地利用计算资源，以减少过度预配。 容器业务流程协调程序是一个常见示例。 大型（垂直缩放）计算实例通常用于这些基础结构的资源池中。
命令和查询责任分离 （CQRS） 分隔应用程序的数据模型的读取和写入作。 这种分离可实现针对每个作的特定用途的目标性能和缩放优化。 此设计在具有高读写比率的应用程序中非常有用。
部署戳 根据假设将相同或不同的版本同时部署，提供一种方法，用于发布应用程序的特定版本及其基础结构作为受控部署单元。 此模式通常与工作负荷中定义的缩放单元保持一致：由于需要超出单个缩放单元提供的额外容量，因此会部署一个额外的部署标记来横向扩展。
事件溯源 将状态更改视为一系列事件，在不可变的仅追加日志中捕获它们。 根据工作负荷，此模式通常与 CQRS（适当的域设计和战略快照）结合使用可以提高性能。 性能改进是由于原子仅追加作和避免数据库锁定写入和读取。
联合标识 将信任委托给工作负荷外部的标识提供者，以管理用户并为应用程序提供身份验证。 卸载用户管理和身份验证时，可以将应用程序资源投入到其他优先级。
把关 在将请求转发到后端节点之前和之后，卸载专门为安全和访问控制强制实施的请求处理。 此模式通常用于在网关级别实现限制，而不是在节点级别实现速率检查。 协调所有节点之间的速率状态并非本质上是高性能的。
网关聚合 通过在单个请求中聚合对多个后端服务的调用，简化了客户端与工作负荷的交互。 与客户端建立多个连接的设计相比，此设计会产生更少的延迟。 缓存在聚合实现中也很常见，因为它最大限度地减少了对后端系统的调用。
网关卸载 将请求转发到后端节点之前和之后，将请求处理卸载到网关设备。 将卸载网关添加到请求过程使你能够使用更少的每个节点的资源，因为功能集中在网关上。 可以独立于应用程序代码优化卸载功能的实现。 卸载的平台提供的功能可能具有很高的性能。
网关路由 根据请求意向、业务逻辑和后端可用性，将传入的网络请求路由到各种后端系统。 网关路由使你能够跨系统中的节点分配流量，以均衡负载。
晶洞 部署跨多个地理位置在主动-主动可用性模式下运行的系统。 此模式使用数据复制来支持任何客户端可以连接到任何地理实例的理想。 可以使用它从离分布式用户群最近的区域为应用程序提供服务。 这样做会通过消除长途流量来降低延迟，并且你仅在当前使用相同的地理区域的用户之间共享基础结构。
运行状况终结点监视 提供一种通过公开专为该目的设计的终结点来监视系统的运行状况或状态的方法。 可以使用这些终结点将流量路由到仅验证为正常的节点来提高负载均衡。 通过其他配置，还可以获取可用节点容量的指标。
索引表 通过使客户端能够查找元数据来优化分布式数据存储中的数据检索，以便直接检索数据，从而避免需要执行完整的数据存储扫描。 客户端指向其分片、分区或终结点，该分片、分区或终结点可以启用动态数据分区以实现性能优化。
具体化视图 使用数据的预计算视图来优化数据检索。 具体化视图存储复杂计算或查询的结果，而无需数据库引擎或客户端重新计算每个请求。 此设计可减少整体资源消耗。
优先级队列 确保在优先级较低的项之前处理和完成高优先级项。 基于业务优先级分离项使你能够将性能工作集中在最耗时的工作上。
发布服务器/订阅服务器 通过将直接客户端到服务或客户端到服务通信替换为通过中间消息代理或事件总线进行通信来分离体系结构的组件。 通过与使用者分离发布者，可以针对使用者需要为特定消息执行的任务优化计算和代码。
Queue-Based 负载调配 通过在队列中缓冲传入请求或任务级别，让队列处理器按受控的速度处理这些请求或任务。 此方法可实现对吞吐量性能的有意设计，因为请求的引入不需要与处理请求的速率相关联。
计划程序代理监督程序 根据系统中可观察到的因素，高效地跨系统分配和重新分发任务。 此模式使用性能和容量指标来检测当前利用率，并将任务路由到具有容量的代理。 还可以使用它来优先执行优先级更高的优先级工作，而优先执行优先级较低的工作。
分片 将加载定向到特定逻辑目标以处理特定请求，从而启用并置以实现优化。 在缩放策略中使用分片时，数据或处理将隔离到分片，因此它只与定向到该分片的其他请求竞争资源。 还可以使用分片根据地理位置进行优化。
Sidecar 通过将非主要任务或交叉任务封装在与主应用程序一起存在的配套进程中来扩展应用程序的功能。 可以将跨切任务移动到单个进程，该进程可跨主进程的多个实例进行缩放，从而减少为每个应用程序实例部署重复功能的需求。
静态内容托管 使用专为该目的设计的托管平台优化静态内容传送到工作负荷客户端。 将责任卸载到外部化主机有助于缓解拥塞，并使你能够仅使用应用程序平台来交付业务逻辑。
限制 对对资源或组件的传入请求的速率或吞吐量施加限制。 当系统需求过高时，此模式有助于缓解可能导致性能瓶颈的拥塞。 还可以使用它来主动避免干扰邻居方案。
附属密钥 授予对资源的安全限制访问权限，而无需使用中间资源来代理访问。 这样做会将处理作为客户端和资源之间的独占关系卸载，而无需以高性能方式处理所有客户端请求的大使组件。 当代理不向事务添加值时，使用此模式的好处最为重要。

后续步骤

查看支持其他 Azure Well-Architected 框架支柱的体系结构设计模式：