微服务划分问题：schedule任务和listener是集中在一起好还是分散在业务服务下好？
微服务划分问题：各种不同业务的scheduler和listener是集中在一起，分别放在一个scheduler和listener的服务里好，还是分散放在其相关的业务服务下好？
各有什么利弊？
譬如listener放在一起，便于复用消息队列网络连接，提升性能？
譬如分散在业务服务下，开发一个有scheduler或者listener的功能时，只需要更新功能所在服务即可，不需要跨服务开发？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
拆得越细,通常架构越复杂, 开发、修改、监控都会变得更复杂, 但好处是收获了可扩展性, 怎么做完全取次于业务需要和团队对技术把握能力. 要对性能做预测, 允许的情况下, 放在一起一般来说更易维护.
scheduler多的话还是单独拆分一个服务比较好，对服务器压力比较小