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

扩大式设计

设计应用程序,使其可进行水平缩放

云的主要优点是可以弹性缩放 — 能够根据需要使用容量,在负载增加时扩大,在不需要额外容量时缩小。 设计应用程序,使其能够水平缩放,添加或删除实例,以满足需求。

可伸缩性由吞吐量增益与资源增加的比例来衡量。 理想情况下,在一个设计良好的系统中,这两个数字是成比例的:资源的双重分配将使吞吐量翻倍。 可伸缩性通常受到系统内引入瓶颈或同步点的限制。

建议

避免实例粘性。 在来自相同客户端的请求始终路由至同一台服务器时,才会出现粘性或会话相关性。 粘性限制了应用程序横向扩展的能力。例如,来自高容量用户的流量不会跨实例分布。 粘性的成因包括在内存中存储会话状态以及使用特定于计算的密钥加密。 请确保任何实例都可处理任何请求。

确定瓶颈。 扩大并不是解决每个性能问题的万能方式。 例如,如果后端数据库是瓶颈,添加再多 Web 服务器也于事无补。 首先识别并解析系统中的瓶颈,然后针对该问题引发更多实例。 系统中有状态的部分最有可能引起瓶颈问题。

通过可伸缩性要求分解工作负荷 应用程序通常由多个工作负荷组成,它们的缩放要求各不相同。 例如,应用程序可能有面向公众的网站和单独的管理网站。 公众网站可能会遇到流量突然激增的情况,而管理网站的负荷更小,且更具可预测性。

设计通过异步通信协议进行通信的自主组件和分离组件。 理想情况下,组件应有自己的独立状态,并使用事件将任何更改或活动传达给外部组件。 这有助于仅独立缩放重载的组件。 实现流控制机制来管理流量和正常降级。 使用者应控制自己的消耗率。 生产者应控制自己的传输速率,包括停止。 消息队列是吸收额外工作负荷并让使用者在闲暇时清空工作的好选择。

避免不必要的通信、协调和等待。

卸载自然异步任务。 发送电子邮件、执行用户不需要立即响应的操作以及与其他系统集成等任务都适合使用异步消息传送模式

卸载资源密集型任务 需要大量的 CPU 或 I/O 资源的任务应尽可能移动到后台作业以减少处理用户请求的前端上的负载。

基于实时使用情况指标自动缩放并使用内置自动缩放功能。 许多 Azure 计算服务有内置的自动缩放支持。 如果应用程序具有可预测的常规工作负荷,则可按计划扩大。 例如,在营业时间期间扩大。 否则,如果工作负荷不可预测,则可使用 CPU 或请求队列长度等性能指标来触发自动缩放。 观察应用程序及其通信,确定瓶颈并得出更准确的决策。 有关自动缩放最佳做法的信息,请参阅自动缩放

请为关键工作负荷考虑自动缩放。 对于关键工作负荷,你希望供应一直超过需求。 在负载加重的情况下,最好是快速添加新实例来处理额外的流量,然后逐渐缩减。

缩小式设计。 请记住,使用弹性缩放时,应用程序会有缩小时期,此时实例会被移除。 应用程序必须妥善处理正在移除的实例。 以下是一些处理缩小功能的方法:

  • 侦听关闭事件(可用时),然后全部关闭。
  • 服务的客户端/使用者应支持暂时性故障处理和重试。
  • 对于运行时间长的任务,请考虑使用检查点,或者管道和筛选器模式分解工作。
  • 如果实例是在处理过程中移除的,请将工作项放在队列中,以便另一个实例可以接收工作。

考虑针对冗余进行缩放。 横向扩展可以提高应用程序的可靠性。 例如,考虑跨多个可用性区域横向扩展,例如使用区域冗余服务。 此方法可以提高应用程序的吞吐量,并可在某个区域遇到中断问题时提供复原能力。

对系统的可伸缩性进行建模并优化。 可以使用阿姆达尔定律等方法对系统进行建模。 根据争用和一致性等参数量化可伸缩性。 争用是指由于等待或排队共享资源而导致延迟。 一致性是指数据变得一致的延迟。 例如,具有高争用性表示可以并行化的顺序处理;而具有高一致性则表示进程之间存在过度依赖,提示你尽量减少交互。 在工作负载设计过程中,可以计算系统的最大有效容量,以避免提供比需求多的供应,从而导致浪费