微服务间如何选择推送和拉取数据

在如今的系统架构中，服务间会大量采用消息来进行通讯。在消息系统中，通常有两种消费模式：生产端推送和消费端拉取。那么在什么状况下，咱们采用生产端推送，什么状况下换为消费端拉取呢？今天本篇文章就针对这个话题谈谈我我的的想法，但愿对你们有用。

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

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

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

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

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

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

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

推送的优势

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

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

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

推送的缺点

1. 不能确保发送成功，若是生产端推送失败，须要生产端维护失败的推送。

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

总结

前面简单总结了一些推送和拉取的适用场景和区别。实际工做中，服务之间的交互是会采用混合式的，例如，“先推后拉”，“先拉后推”等等，在不一样的业务场景下，服务间的交互方式会作对应的调整。你们也能够谈谈你工做中采用的服务交互方法，欢迎留言。

扫描二维码或手动搜索微信公众号： ForestNotes

欢迎转载，带上如下二维码便可