构建基于SpringCloudStream的消息驱动微服务用于处理第三方开发者接受微信大量推送消息的解决方法，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
成都创新互联公司-专业网站定制、快速模板网站建设、高性价比叙永网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式叙永网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖叙永地区。费用合理售后完善，十余年实体公司更值得信赖。
事情的起因源于在使用微信公众号服务的时候，作为一个第三方的服务商，腾讯会将各种业务消息推送到第三方开发者的服务器上，而之前的方案是消息直接进到服务上，当使用到一些业务，比如发券等操作时，腾讯服务器会向开发者发送大量的消息，由于消息服务的处理能力有限，尤其是高峰的时候，消息请求会直接压到服务上，导致服务线程繁忙，这时候会报大量服务超时，触发微信的服务报警，服务不可用，或者服务超时，这时公众号内的消息服务将无法继续为用户提供服务。鉴于此问题，我们重新梳理并构建了基于Spring Cloud Stream的消息驱动的微服务
我们采用 Spring Cloud Finchley.SR2，Spring Boot 2.0.6.RELEASE 版本来开发，系统的初步设计思路，是利用
消息队列rabbitmq来解耦服务，来减缓消息直接到服务上的压力，我们没有直接对接mq来使用，而是采用了Spring Cloud Stream, 简单的来说，Spring Cloud Stream是构建消息驱动的微服务应用程序的框架，将消息整合的处理操作进行了进一步的抽象操作， 实现了更加简化的消息处理， 可以使用不同的代理中间件，它抽象了事件驱动的一些概念,对于消息中间件的进一步封装,可以做到代码层面对中间件的无感知，甚至于动态的切换中间件，切换topic。使得微服务开发的高度解耦，服务可以关注更多自己的业务流程。
Spring Cloud Stream的一些基本概念可以自行搜索，这里不做过多描述，下面只是讲述一下具体方案和配置方法及遇到的问题。
基本结构是一个非常简单的消息订阅发布模式
至此整个消息处理的基本结构就描述完成了，当然实际的开发过程中，还要考虑消息的异步处理，多线程去处理等，这里就不详尽描述了，需要根据自己的业务需要来实现相应的开发，
有几点注意的情况：
@StreamListener(ReceiveInputChannel.MSG_RECEIVER) 这个方法只能放到Application 服务启动的类中，放到别的地方会报错：Disp org.springframework.integration.MessageDispatchingException: Dispatcher has no subscribers，可能和类的加载顺序有关系。这样在启动类中接受消息，然后可以再通过业务拆分，将消息转到其他的类中实现各自业务逻辑开发。
根据不同的消息中间件，选择不同的依赖。
当接收消息过多的时候，可以增加消息生产者实例来加大消息的接受能力，当消费者处理大量阻塞消息时，处理能力下降，可以通过增加负载的消费者服务实例数量来加大消费能力，这个需要通过实际情况找到平衡点，消息队列作为缓存，降低了由于消息直接压到服务器上而导致的服务崩溃问题的风险。
看完上述内容，你们掌握构建基于SpringCloudStream的消息驱动微服务用于处理第三方开发者接受微信大量推送消息的解决方法的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注创新互联行业资讯频道，感谢各位的阅读！
