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

支持成本优化的云设计模式

  • 项目

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

许多设计模式直接支持一个或多个体系结构支柱。 支持成本优化支柱的设计模式与实现有利的计费模型、减少过度预配、更改缩放维度以及实现迁移期间的价值最大化保持一致。

成本优化的设计模式

下表汇总了支持成本优化目标的云设计模式。

模式 总结
声明检查 将数据与消息流分开，从而提供一种单独检索与消息相关的数据的方法。 消息传送系统通常会对消息大小施加限制，而增加大小限制通常是一项高级功能。 减小消息正文的大小可能会使你能够使用更便宜的消息传送解决方案。
竞争性使用者 应用分布式和并发处理，以高效处理队列中的项。 此模式可以通过启用基于队列深度的缩放（当队列为空时向下缩放到零）来帮助优化成本。 它还可以通过限制并发使用者实例的最大数量来优化成本。
计算资源合并 通过增加密度优化和整合计算资源。 此模式将共享基础结构上的工作负荷的多个应用程序或组件组合在一起。 这样做可以通过聚合组件甚至池基础结构上的整个工作负载来避免未使用的预配容量，从而最大程度地提高计算资源的利用率。 容器业务流程协调程序是一个常见示例。
网关卸载 在将请求转发到后端节点之前和之后，将请求处理卸载到网关设备。 通过将卸载网关添加到请求过程中，可以将成本从每个节点花费的资源重定向到网关实现中。 集中式处理模型中的成本通常低于分布式模型的成本。
消息传送桥 提供一个中介，用于在因协议或格式而不兼容的消息传送系统之间启用通信。 此中介可以延长现有系统的寿命，同时仍允许与使用不同消息传送或事件技术的系统的互操作性。
发布方/订阅方 通过使用中间消息中转站或事件总线，将直接客户端到服务或客户端到服务的通信替换为通信，从而分离体系结构的组件。 此设计可以在体系结构中启用事件驱动方法，该方法与基于消耗的计费很好地结合，以避免过度预配。
基于队列的负载调控 通过在队列中缓冲传入请求或任务，并让队列处理器以受控的速度处理它们，来控制传入请求或任务的级别。 由于负载处理与请求或任务引入分离，因此可以使用此方法减少过度预配资源以处理峰值负载的需求。
分片 将负载定向到特定的逻辑目标以处理特定请求，从而启用归置进行优化。 实现分片的系统通常受益于使用成本较低的计算或存储资源的多个实例，而不是单个更昂贵的资源。 在许多情况下，此配置可以节省资金。
静态内容托管 通过使用专为该目的设计的托管平台，优化向工作负载客户端传递静态内容的方式。 动态应用程序主机通常比静态主机更昂贵，因为动态主机可以运行编码的业务逻辑。 使用应用程序平台传送静态内容并不经济高效。
Strangler Fig 提供一种方法，用于系统地将正在运行的系统的组件替换为新组件，通常在系统迁移或现代化期间。 此方法的目标是在以增量方式实现现代化的同时，最大限度地利用当前正在运行的系统中的现有投资。 它使你能够在低 ROI 更换之前执行高 ROI 替换。
限制 对资源或组件的传入请求的速率或吞吐量施加限制。 这些限制可以告知成本建模，甚至可以直接绑定到应用程序的业务模型。 它们还明确了利用率上限，这可以纳入资源大小调整。
附属密钥 授予对资源的安全限制访问权限，而无需使用中间资源来代理访问。 此设计将处理作为客户端与资源之间的独占关系卸载，而无需添加组件来直接处理所有客户端请求。 当客户端请求频繁或足够大，需要大量代理资源时，这种优势最为显著。

后续步骤

查看支持其他 Azure Well-Architected Framework 支柱的云设计模式：