内容简介：作者简介：ASCE1885，本文由于潜在的商业目的，未经授权不开放全文转载许可，谢谢！
作者简介：ASCE1885， 《Android 高级进阶》 和 《Android 高级进阶(源码剖析篇)》 作者
本文由于潜在的商业目的，未经授权不开放全文转载许可，谢谢！
在分布式架构中，前端一个请求会经过后端的多个服务的处理才返回结果，这时就可能会存在一种情况，在间歇性高负载情况下，某个服务 B 的处理能力不能满足负载的需求，从而导致服务 B 崩溃或者服务调用者 A 响应超时，如下图所示：
那么如何解决这种问题呢？有读者可能会说，那就给服务 B 作单机性能优化，从而提升单机处理能力，进而提升服务 B 集群的整体处理能力；或者当单机处理能力已经无法进一步优化或者即使优化后仍然无法满足负载需求时，那么就对服务 B 集群进行水平扩容，从而提升集群整体的处理能力。
没错，这是一种常见的解决方案，但如果服务 B 集群扩容成本很高呢？例如服务 B 需要用到 GPU 来跑 AI 模型，而我们知道 GPU 成本不低。有一种解决方案是通过引入消息队列（例如 Kafka，RabbitMQ 等）来作为缓冲区，从而最小化请求峰值对服务可用性和响应性的影响（当然，也要考虑具体业务场景是否适合使用这种方式），如下图所示：
引入消息队列后，原来的同步调用变为异步执行，服务 A 将原来的请求封装成消息，发送到消息队列中，而服务 B 则根据自己的处理节奏从消息队列中获取消息进行处理，消息队列起到缓冲区的作用。这样即使服务 A 集群对服务 B 集群发起大量的并发请求，也不会导致服务 B 集群处理不过来甚至崩溃。
当然这种模式也适用于进程内的流量削峰，我们只需把上面的服务 A 和服务 B 替换成同一个应用进程内的模块间调用，而消息队列则替换成进程内的队列实现方案（例如 Disruptor）即可， 模式是活的，具体如何应用就看使用者的水平了 。
参考资料： Queue-Based Load Leveling pattern
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
