170317、到底什么时候该使用MQ？

一、缘起

一切脱离业务的架构设计与新技术引入都是耍流氓。

引入一个技术之前&＃xff0c;首先应该解答的问题是&＃xff0c;这个技术解决什么问题。

就像微服务分层架构之前&＃xff0c;应该首先回答&＃xff0c;为什么要引入微服务&＃xff0c;微服务究竟解决什么问题&＃xff08;详见《互联网架构为什么要做微服务&＃xff1f;》&＃xff09;。

最近分享了几篇MQ相关的文章&＃xff1a;

《MQ如何实现延时消息》

《MQ如何实现消息必达》

《MQ如何实现幂等性》

不少网友询问&＃xff0c;究竟什么时候使用MQ&＃xff0c;MQ究竟适合什么场景&＃xff0c;故有了此文。

二、MQ是干嘛的

消息总线&＃xff08;Message Queue&＃xff09;&＃xff0c;后文称MQ&＃xff0c;是一种跨进程的通信机制&＃xff0c;用于上下游传递消息。

在互联网架构中&＃xff0c;MQ是一种非常常见的上下游“逻辑解耦&＃43;物理解耦”的消息通信服务。

使用了MQ之后&＃xff0c;消息发送上游只需要依赖MQ&＃xff0c;逻辑上和物理上都不用依赖其他服务。

三、什么时候不使用消息总线

既然MQ是互联网分层架构中的解耦利器&＃xff0c;那所有通讯都使用MQ岂不是很好&＃xff1f;这是一个严重的误区&＃xff0c;调用与被调用的关系&＃xff0c;是无法被MQ取代的。

MQ的不足是&＃xff1a;

1&＃xff09;系统更复杂&＃xff0c;多了一个MQ组件

2&＃xff09;消息传递路径更长&＃xff0c;延时会增加

3&＃xff09;消息可靠性和重复性互为矛盾&＃xff0c;消息不丢不重难以同时保证

4&＃xff09;上游无法知道下游的执行结果&＃xff0c;这一点是很致命的

举个栗子&＃xff1a;用户登录场景&＃xff0c;登录页面调用passport服务&＃xff0c;passport服务的执行结果直接影响登录结果&＃xff0c;此处的“登录页面”与“passport服务”就必须使用调用关系&＃xff0c;而不能使用MQ通信。

无论如何&＃xff0c;记住这个结论&＃xff1a;调用方实时依赖执行结果的业务场景&＃xff0c;请使用调用&＃xff0c;而不是MQ。

四、什么时候使用MQ

【典型场景一&＃xff1a;数据驱动的任务依赖】

 什么是任务依赖&＃xff0c;举个栗子&＃xff0c;互联网公司经常在凌晨进行一些数据统计任务&＃xff0c;这些任务之间有一定的依赖关系&＃xff0c;比如&＃xff1a;

1&＃xff09;task3需要使用task2的输出作为输入

2&＃xff09;task2需要使用task1的输出作为输入

这样的话&＃xff0c;tast1, task2, task3之间就有任务依赖关系&＃xff0c;必须task1先执行&＃xff0c;再task2执行&＃xff0c;载task3执行。

对于这类需求&＃xff0c;常见的实现方式是&＃xff0c;使用cron人工排执行时间表&＃xff1a;

1&＃xff09;task1&＃xff0c;0:00执行&＃xff0c;经验执行时间为50分钟

2&＃xff09;task2&＃xff0c;1:00执行&＃xff08;为task1预留10分钟buffer&＃xff09;&＃xff0c;经验执行时间也是50分钟

3&＃xff09;task3&＃xff0c;2:00执行&＃xff08;为task2预留10分钟buffer&＃xff09;

这种方法的坏处是&＃xff1a;

1&＃xff09;如果有一个任务执行时间超过了预留buffer的时间&＃xff0c;将会得到错误的结果&＃xff0c;因为后置任务不清楚前置任务是否执行成功&＃xff0c;此时要手动重跑任务&＃xff0c;还有可能要调整排班表

2&＃xff09;总任务的执行时间很长&＃xff0c;总是要预留很多buffer&＃xff0c;如果前置任务提前完成&＃xff0c;后置任务不会提前开始

3&＃xff09;如果一个任务被多个任务依赖&＃xff0c;这个任务将会称为关键路径&＃xff0c;排班表很难体现依赖关系&＃xff0c;容易出错

4&＃xff09;如果有一个任务的执行时间要调整&＃xff0c;将会有多个任务的执行时间要调整

无论如何&＃xff0c;采用“cron排班表”的方法&＃xff0c;各任务耦合&＃xff0c;谁用过谁痛谁知道&＃xff08;采用此法的请评论留言&＃xff09;

优化方案是&＃xff0c;采用MQ解耦&＃xff1a;

1&＃xff09;task1准时开始&＃xff0c;结束后发一个“task1 done”的消息

2&＃xff09;task2订阅“task1 done”的消息&＃xff0c;收到消息后第一时间启动执行&＃xff0c;结束后发一个“task2 done”的消息

3&＃xff09;task3同理

采用MQ的优点是&＃xff1a;

1&＃xff09;不需要预留buffer&＃xff0c;上游任务执行完&＃xff0c;下游任务总会在第一时间被执行

2&＃xff09;依赖多个任务&＃xff0c;被多个任务依赖都很好处理&＃xff0c;只需要订阅相关消息即可

3&＃xff09;有任务执行时间变化&＃xff0c;下游任务都不需要调整执行时间

需要特别说明的是&＃xff0c;MQ只用来传递上游任务执行完成的消息&＃xff0c;并不用于传递真正的输入输出数据。

【典型场景二&＃xff1a;上游不关心执行结果】

上游需要关注执行结果时要用“调用”&＃xff0c;上游不关注执行结果时&＃xff0c;就可以使用MQ了。

举个栗子&＃xff0c;58同城的很多下游需要关注“用户发布帖子”这个事件&＃xff0c;比如招聘用户发布帖子后&＃xff0c;招聘业务要奖励58豆&＃xff0c;房产用户发布帖子后&＃xff0c;房产业务要送2个置顶&＃xff0c;二手用户发布帖子后&＃xff0c;二手业务要修改用户统计数据。

对于这类需求&＃xff0c;常见的实现方式是&＃xff0c;使用调用关系&＃xff1a;

帖子发布服务执行完成之后&＃xff0c;调用下游招聘业务、房产业务、二手业务&＃xff0c;来完成消息的通知&＃xff0c;但事实上&＃xff0c;这个通知是否正常正确的执行&＃xff0c;帖子发布服务根本不关注。

这种方法的坏处是&＃xff1a;

1&＃xff09;帖子发布流程的执行时间增加了

2&＃xff09;下游服务当机&＃xff0c;可能导致帖子发布服务受影响&＃xff0c;上下游逻辑&＃43;物理依赖严重

3&＃xff09;每当增加一个需要知道“帖子发布成功”信息的下游&＃xff0c;修改代码的是帖子发布服务&＃xff0c;这一点是最恶心的&＃xff0c;属于架构设计中典型的依赖倒转&＃xff0c;谁用过谁痛谁知道&＃xff08;采用此法的请评论留言&＃xff09;

优化方案是&＃xff0c;采用MQ解耦&＃xff1a;

1&＃xff09;帖子发布成功后&＃xff0c;向MQ发一个消息

2&＃xff09;哪个下游关注“帖子发布成功”的消息&＃xff0c;主动去MQ订阅

采用MQ的优点是&＃xff1a;

1&＃xff09;上游执行时间短

2&＃xff09;上下游逻辑&＃43;物理解耦&＃xff0c;除了与MQ有物理连接&＃xff0c;模块之间都不相互依赖

3&＃xff09;新增一个下游消息关注方&＃xff0c;上游不需要修改任何代码

典型场景三&＃xff1a;上游关注执行结果&＃xff0c;但执行时间很长

 有时候上游需要关注执行结果&＃xff0c;但执行结果时间很长&＃xff08;典型的是调用离线处理&＃xff0c;或者跨公网调用&＃xff09;&＃xff0c;也经常使用回调网关&＃43;MQ来解耦。

举个栗子&＃xff0c;微信支付&＃xff0c;跨公网调用微信的接口&＃xff0c;执行时间会比较长&＃xff0c;但调用方又非常关注执行结果&＃xff0c;此时一般怎么玩呢&＃xff1f;

一般采用“回调网关&＃43;MQ”方案来解耦&＃xff1a;

1&＃xff09;调用方直接跨公网调用微信接口

2&＃xff09;微信返回调用成功&＃xff0c;此时并不代表返回成功

3&＃xff09;微信执行完成后&＃xff0c;回调统一网关

4&＃xff09;网关将返回结果通知MQ

5&＃xff09;请求方收到结果通知

这里需要注意的是&＃xff0c;不应该由回调网关来调用上游来通知结果&＃xff0c;如果是这样的话&＃xff0c;每次新增调用方&＃xff0c;回调网关都需要修改代码&＃xff0c;仍然会反向依赖&＃xff0c;使用回调网关&＃43;MQ的方案&＃xff0c;新增任何对微信支付的调用&＃xff0c;都不需要修改代码啦。

五、总结

MQ是一个互联网架构中常见的解耦利器。

什么时候不使用MQ&＃xff1f;

上游实时关注执行结果

什么时候使用MQ&＃xff1f;

1&＃xff09;数据驱动的任务依赖

2&＃xff09;上游不关心多下游执行结果

3&＃xff09;异步返回执行时间长