在现在的系统架构中，服务间会大量采用消息来进行通信。在消息系统中，一般有两种消费模式：生产端推送和消费端拉取。那么在什么情况下，我们采用生产端推送，什么情况下换为消费端拉取呢？今天本篇文章就针对这个话题谈谈我个人的想法，希望对大家有用。

简单来说，是由实际业务决定、包括通信间的双方系统的技术实现、双方系统的架构和性能，看日后是否此业务会经常修改等多方面决定的。

 

数据是动态的且实时性强，宜采用生产端推送

订单系统有一些订单数据，供应链系统需要订单系统的订单数据，并做后续处理。例如， 订单系统的订单支付完成之后会转到供应链系统中做出库，配送等处理。

我相信绝大多数做供应链系统的时候，都会决定在订单系统的订单付完款之后，把订单数据推送到供应链系统中。如果要让供应链系统去轮循地查询订单系统的订单数据是否被付款，不仅不能保证发货的实时性和准确性，而且系统性能上也会有不必要的消耗，供应链系统还要被迫处理重复订单的问题。但注意一点的是，如果将推送设计成实时推送也是不合适的，推送成功与否不应是判断订单是否成功的条件，供应链系统与订单系统并不是强关联的，正确的做法是订单付完款的动作后，做推送的动作设计成异步，通过消息机制，推送到供应链系统，供应链系统在接收到订单后也会反馈一个接收成功的消息给订单系统，进入发货流程。

 

数据有多样性需求且实时性不强，宜采用消费端拉取

CRM系统需要拉取订单数据展示，CRM系统要做一个报表展示或实时性不强的操作。这种情况就可以设计成系统主动去拉订单系统的订单数据，然后根据CRM系统的业务维度，分析订单数据，展示订单数据。这样做可减轻订单系统的压力。为了提升性能，可以采取分页形式来拉取数据，通过队列分组处理订单数据，对于重复数据，可以记录时间戳的形式来解决，时间戳要持久化在CRM系统中。

 

最后我们来总结一下推送和拉取的优缺点。

推送的优点

1. 实时性高。消费者服务能第一时间拿到更新数据。

2. 服务压力小。相比于拉取模式，每次推送都有数据，避免空轮询消耗资源。

3. 交互简单。推送模式中，消费者只需要提供接受数据接口即可，不需要额外的开销。

推送的缺点

不能确保发送成功，如果生产端推送失败，需要生产端维护失败的推送。

缺乏数据的多样性，推送的数据的内容格式一致，可能会有比较大的数据冗余存在，不能根据消费端的不同需求进行变化。

总结

前面简单总结了一些推送和拉取的适用场景和区别。实际工作中，服务之间的交互是会采用混合式的，

例如，“先推后拉”，“先拉后推”等等，在不同的业务场景下，服务间的交互方式会做对应的调整。

大家也可以谈谈你工作中采用的服务交互方法，欢迎留言。