软件开发中，系统之间如何选择推送和拉取数据？

?

一、A  系统有一些订单数据，B  系统需要  A  系统的订单数据，并做一些处理。比如  A  系统的订单支付完成之后会转到  B  系统中做销售结算、销售出库等处理。

这种情况我相信大部分人都会决定在  A  系统的订单付完款之后，把订单数据推送到  B  系统中。因为这样选择是合理的。WHY？如果要让  B  系统去轮循地查询  A  系统的订单数据是否被付款，不仅在实时性和准确性上有缺陷，而且在A、B  系统性能上也会有影响，还要处理重复订单问题。所以说由  A  系统推送订单数据到  B  系统是合理的，但这时如果在设计时只是简单地在  A  系统付完款这里做一个推送动作到  B  系统，这其实是不妥的，如果要碰到推送失败，那么如何再推送一次呢？如果把这个推送动作设计成串行的，那会影响到原有流程。所以在这里设计时，要在订单付完款的动作后做推送的动作设计成异步，也可以做成消息机制，由专门的程序去接收消息，并推送到  B  系统，B  系统在接收到订单后要反馈接收成功标志，并且要对重复订单做处理。这才是一个比较完整的处理逻辑。

二、A  系统有一些订单数据，B  系统需要  A  系统的订单数据展示给客户，比如  B  系统要做一个 表展示或实时性不强的操作（比如根据订单生成销售结算的凭证，一天可做一次）。

这种情况就可以设计成  B  系统主动去拉  A  系统的订单数据，然后根据  B  系统的业务维度，分析订单数据，展示订单数据。这样做可减轻  A  系统的压力。但这样做同时也要注意 络带宽、B  系统的数据处理性能的高低与重复数据的处理。对于 络带宽，可以采取分页形式来拉取数据，对于数据处理的性能问题，可以通过管道和队列来一组一组处理订单数据，对于重复数据，可以通过时间戳的形式来解决，时间戳要持久化在  B  系统中。最后也不要忘了在  A  系统中设计视图、中间表甚至 表数据库来作为数据源，最好不要直接操作订单表（读写分离）。

综述，不管是选用哪种形式，都要根据业务的特性来设计，合理地利用接口来实现业务，必要时选用管道、队列、视图、异步、消息队列等方法。