分享个人想法:消息消费者是独立部署还是跟站点一起部署的考虑

游北亮
博客专家认证
2019-03-27 11:02:38
在当前互联网场景下,消息队列作为业务解耦的中间件服务,已经越来越多的得到了应用;
但是,在实际的部署中,我发现有相当多的开发人员,把队列的消费代码,直接写到了Web站点的代码里,并且部署上线。

应该说,在小规模的应用场景下,这种作法没有太大的问题:
- 开发简单,一个项目完成所有业务场景;
- 部署简单,只需要部署一个站点就完事了,后续的更新维护和日志排查,也只需要看一个地方就ok。

但是,在规模较大,或一些相对复杂的应用场景下,这么部署会存在如下问题:
- 消息消费必然会占用线程,在并发高时,会导致线程不足,无法及时接收用户请求;尤其是消息处理慢的场景;
- 站点启动时会自动启动消费者,不受nginx或服务注册控制,
在有隐藏bug的代码发布预发环境时,无法进行验证就自动上线了,
只能添加额外的是否开启消费者开关,增加开发复杂性;
- 消息突增造成消费者阻塞时,必然对站点服务造成影响,在考虑解决方案时也要评估对站点的影响面;
- 消费者业务逻辑修改和发布,也需要站点停服,在业务高峰时一般不允许站点停服。
基于这4个原因考虑,我一般都是要求:消费者作为独立进程,分开部署,不允许跟站点一起部署;
开发时,如果是DotNet Core或Java服务,可以在一个项目里开发,用同一套代码分别部署站点 和 消费者进程,
部署的消费者进程,不应对用户开放服务(不进行服务注册,也不加入nginx后端)。
...全文
123 1 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
1 条回复
切换为时间正序
请发表友善的回复…
发表回复
游北亮 2019-03-27
  • 打赏
  • 举报
回复
但是同事不是很认可,他的建议是: - 消息处理本质上也是对业务请求的响应,只不过请求方是MQ而已,如果不存在性能问题,业务逻辑简单的,还是应该跟关联业务一起部署,降低部署和维护的复杂性; - 性能低下的,耗时较长的,业务逻辑复杂的,或者依赖较多的消费者,可以考虑独立部署。 - 不应该一刀切,要根据业务实际情况考虑。 大家也帮忙看看,这2种作法有没有其它的优缺点。

111,098

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • AIGC Browser
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧