(十七)—— 基于队列的负载均衡模式.pdf

（⼗七）—— 基于队列的负载均衡模式 云计算设计模式 （⼗七）——基于队列的负载均衡模式 使⽤队列，作为⼀项任务，它调⽤才能顺利间歇重物，可能会以其他⽅式导致失 的 服务或任务超时服务之间的缓冲区。这个模式可以帮助最⼩化峰中的可⽤性和响应需 求为任务和服务的影响。 背景和问题 许多解决⽅案在云中涉及运⾏调⽤服务的任务。在这种环境下，如果⼀个服务进⾏间 歇重物，它可能会导致性能或可靠性问题 ⼀个服务可以是⼀个组件，它是相同的溶液作为利⽤它的任务的⼀部分，或者它可以 是第三⽅服务提供访问经常使⽤的资源，如⾼速缓存或存储服务。如果相同的服务是 由多个同时运⾏的任务的使⽤，它可以是难以预料到的服务可能在任何给定时间点来 进⾏请求的数量。 它可能是⼀个服务可能会遇到在需求⾼峰，导致它变得过载和不能对及时响应请求。 有⼤量的并发请求驱服务也可能会导致服务失 ，如果它不能处理的论点，即这些请 求可能导致。 解决⽅案 重构的解决⽅案和介绍的任务和服务之间的队列。任务和服务异步运⾏。任务帖含有 由服务于⼀个队列所需要的数据的消息。队列作为缓冲，存储该消息，直到它被检索 到的服务。该服务从队列中检索消息并进⾏处理。从多个任务，它可以在⼀个⾼度可 变的速率产⽣的请求，可以通过同⼀个消息队列被传递给服务。图1⽰出了这种结 构。 图1 - 使⽤队列⽔平上的服务的负载 队列有效地从服务解耦的任务，并且该服务可以按⾃⼰的速度处理从并⾏任务的请求 量的信息⽆关。此外，不存在延迟到⼀个任务，如果该服务是不可⽤的时候它投递⼀ 个消息到队列中。 这种模式提供了以下好处： 它可以帮助最⼤限度地提⾼可⽤性，因为服务⽽产⽣的延迟将不会对应⽤程 序，它可以继续发布消息队列，即使该服务不可⽤或不正在处理消息的即时和 直接的影响。 它可以有助于最⼤化可扩展性，因为队列的数⽬和服务的数量可以变化，以满 ⾜需求。 它可以有助于控制成本，因为服务实例的数量部署仅需要⾜以满⾜平均负荷， ⽽不是峰值负荷。 注意：有些服务可以实现节流，如果需求达到阈值，超过该系统可能会失 。节流可 能会降低功能可⽤。你也许可以实现与这些服务负载均衡，以确保这⼀阈值没有达 到。 问题和注意事 在决定如何实现这个模式时，请考虑以下⼏点： 来实现控制的速率服务处理消息，以避免急剧的⽬标资源的应⽤程序逻辑是必 要的。避免将尖峰需求到该系统的下⼀个阶段。测试系统在负载下，以确保它 提供所需的流平，并调整队列的数⽬和处理消息来实现该服务实例的数量。 消息队列是⼀个单向的沟通机制。如果⼀个任务期望的服务的答复，可能有必 要执⾏该服务可⽤于发送的响应的机制。欲了解更多信息，请参阅异步消息底 漆。 您⼀定要⼩⼼，如果你申请⾃动缩放到被监听的队列中的请求服务，因为这可 能会导致更多的争夺任何资源，这些服务的份额，并减少使⽤队列级负载的有 效性。 何时使⽤这个模式 此图案是⾮常适合于使⽤可能会受到重载服务的任何类型的应⽤程序。 这种模式可能不是合适的，如果该应⽤程序期望以最⼩延迟的服务的响应。 例⼦ 微软的 Azure Web ⾓⾊存储数据使⽤单独的存储服务。如果⼤量的 Web ⾓⾊实例同 时运⾏，则可能是存储服务可以是不堪重负，⽆法向请求的速度不够快，以防⽌超时 或没有响应这些请求。图 2 列出了这个问题。 图2 - 服务从⼀个 Web ⾓⾊实例⼤量并发请求正在被压垮 要解决此问题，可以使⽤⼀个队列地级Web⾓⾊实例和存储服务之间的负载。但是， 存储服务被设计为接受同步请求，并且不能很容易地修改，以读取信息以及管理的吞 吐量。因此，可以引⼊⼀个辅助⾓⾊作为接收从该队列中的请求，并将其转发到所述 存储服务的代理服务。在辅助⾓⾊的应⽤程序逻辑可以控制在它传递请求到存储服 务，以防⽌存储服务从被压垮的速率。图3⽰出了这种解决⽅案。 图3 - 使⽤队列和辅助⾓⾊成⽔平的幅作⽤和服务实例之间的负载 W3Cschool （ ）最⼤的技术知识分享与学习平台 此篇内容来⾃于 ⽹站⽤户上传并发布。