在任务和调用的服务之间的缓冲区使用队列缓冲负载,避免导致服务失败或任务超时。可以帮助减少需求峰值对任务和服务可用性和响应能力的影响。
问题背景
云中的许多解决方案的任务中都调用了服务。在这种环境中,如果某服务受到间歇性的超载,则会导致任务性能或可用性问题。
服务可以是与任务相同解决方案的一部分,也可以作为提供常用资源(如缓存或存储服务)访问的第三方服务。如果同一服务由多个并发任务使用,则可能预测某时刻服务的请求量。服务可能会遇到请求高峰而导致过载,从而无法及时响应请求。如果服务有大并发请求,无法处理这些请求引起资源争用,甚至会导致服务失败。
解决方案
重构解决方案，在任务和服务之间引入队列。任务和服务异步运行。任务中包含服务所需数据的消息然后发送到队列。队列充当缓冲区存储消息,由服务查询。服务从队列中查询消息并处理它们。可通过相同的消息队列将来自多个任务的请求(速率可变)传给服务。此图显示了使用队列来缓解服务的负载。
服务拿出消息，可按自己的速率处理消息,而不必考虑并发任务的请求量。
此外,向队列发送消息的服务暂时不可用，不会影响任务的处理。
这个模式具有以下优点:
它可以帮助最大限度地提高可用性,因为服务延迟不会直接影响到应用程序,即使服务不可用或当前没有在处理消息,也会继续向队列发送消息。
可以帮助最大限度地提高可伸缩性, 因为队列的数量和服务的数量可以独立变化，组合起来满足需求。
可以帮助控制成本, 因为部署的服务实例只需满足均值负载,而不是峰值负载。
当需求超出可能会导致系统失败的阈值时,一些服务可以实现节流。节流可以暂停可用的功能。可以使用这些服务资源来均衡负载,以确保总负载低于阈值。
问题和注意事项
在决定如何实现此模式时, 请考虑以下几点:
必须小心控制服务处理消息的速率以避免目标资源崩溃。避免将需求峰值传递到系统的下一阶段。负载测试,确保它能支撑足够的负载,可通过调整队列数和处理消息的服务实例数来调优。
消息队列是单向通信。如果任务需要来自服务的答复,则需要发送响应消息的机制。详细信息,请参阅异步消息传递入门。
在将自动伸缩应用到监听请求队列的服务时需谨慎。可能会加剧导致服务间共享资源争用的情况,并降低了使用队列缓解负载的有效性。
何时使用此模式
该模式对于使用了服务的应用程序面临超载情况很有用。
而如果应用程序希望服务尽快响应,则此模式可能不会有用。
例子
微软Azure中Web角色使用单独的存储服务来存储数据。如果web角色有大量实例同时运行,则存储服务可能无法快速响应请求,导致这些请求超时或失败。下图显示了一个服务面临来自web角色实例的大并发请求时超载。
要解决这个问题,可以使用队列在web角色实例和存储服务间对负载进行缓冲。但是存储服务的请求处理是同步的,不能轻易修改。可以引入一个辅助角色,充当接收来自队列的请求并将其转发到存储服务的代理服务。在辅助角色中控制将请求传递到存储服务的速率,以防止存储服务超载。下图说明了使用队列和辅助角色在web角色和服务实例之间进行负载缓冲的示例。
相关阅读
在实现此模式时,以下模式也可能是相关的:
异步消息传递入门。消息队列在本质上是异步的。如果在任务与服务间通信使用消息队列,则可能需要对应用程序重新设计。同样,可能需要重构服务以接收来自消息队列的请求。或者可以像上例一样使用代理服务。
竞争的消费者模式。可能会需要运行服务的多个实例,每个都会负载队列的消费者。可以使用此方法来调节接收并传递给服务的消息速率。
节流模式。对服务进行节流的一种简单方法是使用基于队列的负载均衡,并通过消息队列将所有请求路由到服务。这样可以确保服务所需的资源不会因请求的处理频率过高而耗尽, 并减少可能发生争用的情况。
队列服务。这里包含了Azure应用程序中消息传递和排队的相关信息。