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