您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

扩大式设计Design to scale out

设计应用程序,使其可进行水平缩放Design your application so that it can scale horizontally

云的主要优点是可以弹性缩放 — 能够根据需要使用容量,在负载增加时扩大,在不需要额外容量时缩小。A primary advantage of the cloud is elastic scaling — the ability to use as much capacity as you need, scaling out as load increases, and scaling in when the extra capacity is not needed. 设计应用程序,使其能够扩大,根据需要添加或删除新实例。Design your application so that it can scale horizontally, adding or removing new instances as demand requires.

建议Recommendations

避免实例粘性Avoid instance stickiness. 在来自相同客户端的请求始终路由至同一台服务器时,才会出现粘性或会话相关性。Stickiness, or session affinity, is when requests from the same client are always routed to the same server. 粘性限制了应用程序扩大的能力。例如,来自高容量用户的流量不会跨实例分布。Stickiness limits the application's ability to scale out. For example, traffic from a high-volume user will not be distributed across instances. 粘性的成因包括在内存中存储会话状态以及使用特定于计算的密钥加密。Causes of stickiness include storing session state in memory, and using machine-specific keys for encryption. 请确保任何实例都可处理任何请求。Make sure that any instance can handle any request.

识别瓶颈Identify bottlenecks. 扩大并不是解决每个性能问题的万能方式。Scaling out isn't a magic fix for every performance issue. 例如,如果后端数据库是瓶颈,添加再多 Web 服务器也于事无补。For example, if your backend database is the bottleneck, it won't help to add more web servers. 首先识别并解析系统中的瓶颈,然后针对该问题引发更多实例。Identify and resolve the bottlenecks in the system first, before throwing more instances at the problem. 系统中有状态的部分最有可能引起瓶颈问题。Stateful parts of the system are the most likely cause of bottlenecks.

通过可伸缩性要求分解工作负荷Decompose workloads by scalability requirements. 应用程序通常由多个工作负荷组成,它们的缩放要求各不相同。Applications often consist of multiple workloads, with different requirements for scaling. 例如,应用程序可能有面向公众的网站和单独的管理网站。For example, an application might have a public-facing site and a separate administration site. 公众网站可能会遇到流量突然激增的情况,而管理网站的负荷更小,且更具可预测性。The public site may experience sudden surges in traffic, while the administration site has a smaller, more predictable load.

卸载资源密集型任务Offload resource-intensive tasks. 需要大量的 CPU 或 I/O 资源的任务应尽可能移动到后台作业以减少处理用户请求的前端上的负载。Tasks that require a lot of CPU or I/O resources should be moved to background jobs when possible, to minimize the load on the front end that is handling user requests.

使用内置自动缩放功能Use built-in autoscaling features. 许多 Azure 计算服务有内置的自动缩放支持。Many Azure compute services have built-in support for autoscaling. 如果应用程序具有可预测的常规工作负荷,则可按计划扩大。If the application has a predictable, regular workload, scale out on a schedule. 例如,在营业时间期间扩大。For example, scale out during business hours. 否则,如果工作负荷不可预测,则可使用 CPU 或请求队列长度等性能指标来触发自动缩放。Otherwise, if the workload is not predictable, use performance metrics such as CPU or request queue length to trigger autoscaling. 有关自动缩放最佳做法的信息,请参阅自动缩放For autoscaling best practices, see Autoscaling.

请为关键工作负荷考虑自动缩放Consider aggressive autoscaling for critical workloads. 对于关键工作负荷,你希望供应一直超过需求。For critical workloads, you want to keep ahead of demand. 在负荷加重的情况下,最好快速增加新实例以处理额外的流量,然后再逐渐缩减。It's better to add new instances quickly under heavy load to handle the additional traffic, and then gradually scale back.

缩小式设计Design for scale in. 请记住,使用弹性缩放时,应用程序会有缩小时期,此时实例会被移除。Remember that with elastic scale, the application will have periods of scale in, when instances get removed. 应用程序必须妥善处理正在移除的实例。The application must gracefully handle instances being removed. 以下是一些处理缩小功能的方法:Here are some ways to handle scalein:

  • 侦听关闭事件(可用时),然后全部关闭。Listen for shutdown events (when available) and shut down cleanly.
  • 服务的客户端/使用者应支持暂时性故障处理和重试。Clients/consumers of a service should support transient fault handling and retry.
  • 对于运行时间长的任务,请考虑使用检查点,或者管道和筛选器模式分解工作。For long-running tasks, consider breaking up the work, using checkpoints or the Pipes and Filters pattern.
  • 如果实例是在处理过程中移除的,请将工作项放在队列中,以便另一个实例可以接收工作。Put work items on a queue so that another instance can pick up the work, if an instance is removed in the middle of processing.