服务之间的常见通信方式

服务调用:

消息机制:

什么是MQ

消息队列(Message Queue),是一种跨进程的通信机制,用于上下游传递消息。

消息队列是典型的:生产者、消费者模型

  • 生产者不断向消息队列中生产消息,消费者不断的从队列中获取消息。
  • 因为消息的生产和消费都是异步的,而且只关心消息的发送和接收,没有业务逻辑的侵入,这样就实现了生产者和消费者的解耦。
  • 使用了MQ之后,消息发送上游只需要依赖MQ,逻辑上和物理上都不用依赖其他服务。

MQ的使用场景

什么时候不使用MQ

既然MQ是互联网分层架构中的解耦利器,那所有通讯都使用MQ岂不是很好?

这是一个严重的误区,调用与被调用的关系,是无法被MQ取代的。

MQ的不足是:

  1. 系统更复杂,多了一个MQ组件
  2. 消息传递路径更长,延时会增加
  3. 消息可靠性和重复性互为矛盾,消息不丢不重难以同时保证
  4. 上游无法知道下游的执行结果,这一点是很致命的

举个栗子:

小湖学院系统创建订单场景,创建订单时需要查找课程基本信息,订单服务调用课程服务,课程服务的执行结果直接影响创建订单的结果,此处的“订单服务”与“课程服务”就必须使用调用关系,而不能使用MQ通信。

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

什么时候使用MQ

【典型场景一:数据驱动的任务依赖】

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

  1. task3需要使用task2的输出作为输入
  2. task2需要使用task1的输出作为输入

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

对于这类需求,常见的实现方式是,使用cron人工排执行时间表:

  1. task1,0:00执行,经验执行时间为50分钟
  2. task2,1:00执行(为task1预留10分钟buffer),经验执行时间也是50分钟
  3. task3,2:00执行(为task2预留10分钟buffer)

这种方法的坏处是:

  1. 如果有一个任务执行时间超过了预留buffer的时间,将会得到错误的结果,因为后置任务不清楚前置任务是否执行成功,此时要手动重跑任务,还有可能要调整排班表
  2. 总任务的执行时间很长,总是要预留很多buffer,如果前置任务提前完成,后置任务不会提前开始
  3. 如果一个任务被多个任务依赖,这个任务将会称为关键路径,排班表很难体现依赖关系,容易出错
  4. 如果有一个任务的执行时间要调整,将会有多个任务的执行时间要调整

无论如何,采用“cron排班表”的方法,各任务耦合

优化方案是,采用MQ解耦:

  1. task1准时开始,结束后发一个“task1 done”的消息
  2. task2订阅“task1 done”的消息,收到消息后第一时间启动执行,结束后发一个“task2 done”的消息
  3. task3同理

采用MQ的优点是:

  1. 不需要预留buffer,上游任务执行完,下游任务总会在第一时间被执行
  2. 依赖多个任务,被多个任务依赖都很好处理,只需要订阅相关消息即可
  3. 有任务执行时间变化,下游任务都不需要调整执行时间

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

【典型场景二:上游不关心执行结果】

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

举个栗子,在线教育系统的很多下游需要关注“用户评论课程”这个事件,比如课程服务要增加课程评论数量,积分服务要奖励用户积分,消息服务要给管理员发送站内消息。

对于这类需求,常见的实现方式是,使用调用关系:

用户评论课程执行完成之后,调用下游课程服务、积分服务、消息服务,但事实上,这个通知是否正常正确的执行,帖子发布服务根本不关注。

这种方法的坏处是:

  1. 课程评论发布流程的执行时间增加了
  2. 下游服务宕机,可能导致课程评论服务受影响,上下游逻辑+物理依赖严重
  3. 每当增加一个需要知道“评论发布成功”信息的下游,都要修改课程评论服务的代码,属于架构设计中典型的依赖倒转

优化方案是,采用MQ解耦:

  1. 评论发布成功后,向MQ发一个消息
  2. 哪个下游关注“评论发布成功”的消息,主动去MQ订阅

采用MQ的优点是:

  1. 上游执行时间短
  2. 上下游逻辑+物理解耦,除了与MQ有物理连接,模块之间都不相互依赖
  3. 新增一个下游消息关注方,上游不需要修改任何代码

【典型场景三:上游关注执行结果,但执行时间很长】

有时候上游需要关注执行结果,但执行结果时间很长(典型的是调用离线处理,或者跨公网调用,例如支付、调用阿里云接口等业务),也经常使用回调网关+MQ来解耦。

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

一般采用“回调网关+MQ”方案来解耦:

  1. 调用方直接跨公网调用微信接口
  2. 微信返回调用成功,此时并不代表返回成功
  3. 微信执行完成后,回调统一网关
  4. 网关将返回结果通知MQ
  5. 请求方收到结果通知

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

【典型场景四:缓冲流量,削峰填谷】

高并发场景下的服务通信,不管采用“直接调用”还是“MQ推送”,都有一个缺点,下游消息接收方无法控制到达自己的流量,如果调用方不限速,很有可能把下游压垮。

举个栗子,秒杀业务:

上游发起下单操作

下游完成秒杀业务逻辑(库存检查,库存冻结,余额检查,余额冻结,订单生成,余额扣减,库存扣减,生成流水,余额解冻,库存解冻)

上游下单业务简单,每秒发起了10000个请求,下游秒杀业务复杂,每秒只能处理2000个请求,很有可能上游不限速的下单,导致下游系统被压垮,引发雪崩。

为了避免雪崩,常见的优化方案有两种:

  1. 业务上游队列缓冲,限速发送
  2. 业务下游队列缓冲,限速执行

问:如何缓冲流量?

使用MQ做消息缓冲。由MQ-server推模式,升级为MQ-client拉模式。MQ-client根据自己的处理能力,每隔一定时间,或者每次拉取若干条消息,实施流控,达到保护自身的效果。并且这是MQ提供的通用功能,无需上下游修改代码。

问:如果上游发送流量过大,会不会导致消息在MQ中堆积?

为了避免消息在MQ中堆积,下游消息接收方可以批量处理消息,提升整体吞吐量。

结论

  1. MQ-client提供拉模式,定时或者批量拉取,可以起到削平流量,下游自我保护的作用(MQ需要做的)
  2. 要想提升整体吞吐量,需要下游优化,例如批量处理等方式(消息接收方需要做的)

总结

  • MQ是一个互联网架构中常见的解耦利器。
  • 什么时候不使用MQ?

    • 上游实时关注执行结果
  • 什么时候使用MQ?

    • 数据驱动的任务依赖
    • 上游不关心多下游执行结果
    • 异步返回执行时间长
    • 缓冲流量,削峰填谷

AMQP和JMS

MQ是消息通信的模型,并不是具体实现。现在实现MQ的有两种主流方式:AMQP、JMS。

两者间的区别和联系:(面试)

  • JMS是定义了统一的接口,来对消息操作进行统一;
  • AMQP是通过规定协议来统一数据交互的格式。
  • JMS限定了必须使用Java语言
  • AMQP只是协议,不规定实现方式,因此是跨语言的。
  • JMS规定了两种消息模型;
  • 而AMQP的消息模型更加丰富。

常见的消息中间件产品

  • ActiveMQ:基于JMS
  • RabbitMQ:基于AMQP协议,erlang语言开发,稳定性好
  • RocketMQ:基于JMS,阿里巴巴产品,目前交由Apache基金会
  • Kafka:分布式消息系统,高吞吐量

推荐阅读




腾讯云社区邀请各位技术博主加入,福利多多噢!
Last modification:August 18th, 2020 at 07:17 pm
如果觉得我的文章对你有用,请随意赞赏