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

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

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

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

成本优化的设计模式

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

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

后续步骤

查看支持其他 Azure 良好架构框架支柱的云设计模式: