基于队列的负载均衡模式
使用一个队列，充当任务和它调用的服务之间的缓冲区，以平滑间歇性的重负载导致的服务失败或任务超时。这可以最大限度地帮助减少需求峰值对任务和服务的可用性和响应性的影响。
背景和问题
云中的许多解决方案都涉及运行调用服务的任务。在这种环境下，如果某个服务遭受间歇性的重负载，可能会导致性能或可靠性问题。 服务可以与使用它的任务是同一解决方案的一部分，也可以是提供对常用资源（如缓存或存储服务）的访问的第三方服务。 如果同时运行多个任务使用相同的服务，则可能难以随时预测对服务的请求量。 服务可能会遇到需求高峰导致其过载，无法及时响应请求。如果无法处理这些请求引起的争用，大量并发请求也可能导致服务失败。
解决方案
重构解决方案并在任务和服务之间引入队列。任务和服务异步运行。任务将包含服务所需数据的消息发送到队列。队列充当缓冲区，存储消息，直到被服务检索到。该服务从队列中检索并处理消息。
以高度可变的速率生成的许多任务的请求，可以通过相同的消息队列传递给服务。下图显示使用队列来平衡服务上的负载。
队列将任务从服务中分离出来，服务可以按照自己的速度处理消息，而不管并发任务的请求量如何。此外，如果服务在将消息发送到队列时不可用，则不会有任何延迟。
这种模式提供了以下好处：
- 它可以帮助最大限度地提高可用性，因为在服务中产生的延迟不会对应用程序产生即时和直接的影响，即使服务不可用或者当前没有处理消息，应用程序也可以继续发送消息到队列中。
- 它可以帮助最大限度地提高可扩展性，因为队列和服务数量都可以根据需求而变化。
- 它可以帮助控制成本，因为部署的服务实例数量必须足以满足平均负载而不是峰值负载。
当需求达到系统可能失败的阈值时，一些服务会引入限流。限流可能会降级可用的功能。可以使用这些服务实现负载均衡，以确保达不到此阈值。
问题和注意事项
在决定如何实现这种模式时，请考虑以下几点：
- 有必要实现应用程序逻辑来控制服务处理消息的速率，以避免超出目标资源。避免将需求传递到系统的下一个阶段。对系统进行负载测试，确保它提供所需的负载水平，并调整队列数量和处理消息的服务实例的数量。
- 消息队列是一种单向通信机制。如果任务期望从服务中得到答复，则可能需要实现服务可以用来发送答复的机制。更多相关内容，请参阅异步消息入门。
- 如果将自动伸缩应用于正在侦听队列上的请求的服务，请小心。这可能会导致对这些服务共享的资源争用的增加，并降低使用队列来平衡负载的有效性。
何时使用该模式
这种模式对于任何引发过载服务的应用程序都很有用。 如果应用程序期望延迟最小的服务响应，则此模式不适用。
案例
Microsoft Azure Web角色使用单独的存储服务存储数据。如果Web角色的大量实例并发运行，则存储服务可能无法快速响应请求，以防止这些请求超时或失败。下图强调了一个服务被来自Web角色实例的大量并发请求所淹没。
要解决这个问题，可以使用队列来平衡Web角色实例和存储服务之间的负载。但是，存储服务旨在接受同步请求，不能轻易修改以读取消息和管理吞吐量。可以引入一个辅助角色作为代理服务，接收来自队列的请求并将其转发给存储服务。 worker角色中的应用程序逻辑可以控制将请求传递到存储服务的速度，以防止存储服务被淹没。下图说明了一个队列和一个工作者角色来平衡Web角色和服务的实例之间的负载。
相关的模式和指南
以下模式和指南在实施这种模式时可能是相关的：
- 异步消息入门。消息队列本质上是异步的。如果从一个服务直接与一个服务通信改为使用一个消息队列，那么可能有必要重新设计一个任务中的应用程序逻辑。同样，可能需要重构服务以接受来自消息队列的请求。或者，也可以如案例中所述实现代理服务。
- 竞争消费者模式。运行一个服务的多个实例是可能的，每个实例都作为负载均衡队列中的消息使用者。可以使用此方法来调整接收邮件并将其传递给服务的速率。
- 限流模式。服务实施限流的一个简单方法是使用基于队列的负载均衡，并通过消息队列将所有请求路由到服务。该服务可以确保所需的资源没有用尽的速率来处理请求，并且减少可能发生的争用的量。
- 队列服务概念。介绍了有关在Azure应用程序中选择消息传递和排队机制的内容。