使用队列，作为一项任务，它调用才能顺利间歇重物，可能会以其他方式导致失败的服务或任务超时服务之间的缓冲区。这个模式可以帮助最小化峰中的可用性和响应需求为任务和服务的影响。
背景和问题
许多解决方案在云中涉及运行调用服务的任务。在这种环境下，如果一个服务进行间歇重构，它可能会导致性能或可靠性问题。
一个服务可以是一个组件，它是相同的溶液作为利用它的任务的一部分，或者它可以是第三方服务提供访问经常使用的资源，如高速缓存或存储服务。如果相同的服务是由多个同时运行的任务的使用，它可以是难以预料到的服务可能在任何给定时间点来进行请求的数量。
它可能是一个服务可能会遇到在需求高峰，导致它变得过载和不能对及时响应请求。有大量的并发请求驱服务也可能会导致服务失败，如果它不能处理的论点，即这些请求可能导致。
解决方案
重构的解决方案和介绍的任务和服务之间的队列。任务和服务异步运行。任务帖含有由服务于一个队列所需要的数据的消息。队列作为缓冲，存储该消息，直到它被检 索到的服务。该服务从队列中检索消息并进行处理。从多个任务，它可以在一个高度可变的速率产生的请求，可以通过同一个消息队列被传递给服务。图1示出了这 种结构。
图1 - 使用队列水平上的服务的负载
队列有效地从服务解耦的任务，并且该服务可以按自己的速度处理从并行任务的请求量的信息无关。此外，不存在延迟到一个任务，如果该服务是不可用的时候它投递一个消息到队列中。
这种模式提供了以下好处：
•它可以帮助***限度地提高可用性，因为服务而产生的延迟将不会对应用程序，它可以继续发布消息队列，即使该服务不可用或不正在处理消息的即时和直接的影响。
•它可以有助于***化可扩展性，因为队列的数目和服务的数量可以变化，以满足需求。
•它可以有助于控制成本，因为服务实例的数量部署仅需要足以满足平均负荷，而不是峰值负荷。
注意：
有些服务可以实现节流，如果需求达到阈值，超过该系统可能会失败。节流可能会降低功能可用。你也许可以实现与这些服务负载均衡，以确保这一阈值没有达到。
问题和注意事项
在决定如何实现这个模式时，请考虑以下几点：
•来实现控制的速率服务处理消息，以避免急剧的目标资源的应用程序逻辑是必要的。避免将尖峰需求到该系统的下一个阶段。测试系统在负载下，以确保它提供所需的流平，并调整队列的数目和处理消息来实现该服务实例的数量。
•消息队列是一个单向的沟通机制。如果一个任务期望的服务的答复，可能有必要执行该服务可用于发送的响应的机制。欲了解更多信息，请参阅异步消息底漆。
•您一定要小心，如果你申请自动缩放到被监听的队列中的请求服务，因为这可能会导致更多的争夺任何资源，这些服务的份额，并减少使用队列级负载的有效性。
何时使用这个模式
此图案是非常适合于使用可能会受到重载服务的任何类型的应用程序。
这种模式可能不是合适的，如果该应用程序期望以最小延迟的服务的响应。
例子
微软的Azure Web角色存储数据使用单独的存储服务。如果大量的Web角色实例同时运行，则可能是存储服务可以是不堪重负，无法向请求的速度不够快，以防止超时或没有响应这些请求。图2列出了这个问题。
图2 - 服务从一个Web角色实例大量并发请求正在被压垮
要 解决此问题，可以使用一个队列地级Web角色实例和存储服务之间的负载。但是，存储服务被设计为接受同步请求，并且不能很容易地修改，以读取信息以及管理 的吞吐量。因此，可以引入一个辅助角色作为接收从该队列中的请求，并将其转发到所述存储服务的代理服务。在辅助角色的应用程序逻辑可以控制在它传递请求到 存储服务，以防止存储服务从被压垮的速率。图3示出了这种解决方案。
图3 - 使用队列和辅助角色成水平的幅作用和服务实例之间的负载
本文翻译自MSDN：http://msdn.microsoft.com/en-us/library/dn589783.aspx
博文出处：http://blog.csdn.net/bluecloudmatrix/article/details/48677483
