今天谈下在接口服务设计的时候实时和非实时选择的问题。

在这里特别要注意的是，同步服务并不代表就是实时，同理对于异步服务也不一定就代表是非实时的。因此服务调用的实时性要和同步异步两个概念区分开来。对于同步和异步强调的是服务调用的时候连接是否一直处于等待状态，而对于实时和非实时则强调的是当源系统数据有新增或变化的时候，是否能够第一时间发送到目标系统中去。

我们举例来说明下，假设采购系统有采购订单信息需要同步到ERP系统中去，那么在设计的时候则可能存在多种方式来处理。具体如下：

1) ERP提供导入服务，采购系统同步，实时调用，将数据导入ERP

2) ERP提供导入服务，采购系统异步调用，即先入ESB的MQ中，然后在准实时写入到ERP系统中

3) ERP提供服务，采购系统同步调用，定时将一批新增数据写入到ERP

3) 采购系统提供查询服务，采购系统同步调用，非实时定时调用来获取增量数据信息

可以看到对于服务的设计究竟是采用定时还是实时，跟服务提供方有密切的关系，如果是采购系统提供服务那么只有定时调用进行轮询增量数据，但是如果是ERP系统提供服务，那么选择实现的方法就有很多，即可以是同步异步，实时定时多种方式的组合来实现。

当前的服务设计首先要考虑的是将服务设计为实时服务或者通过MQ的准实时服务，以及时保证数据到多个系统中的一致性。但是当考虑将某个业务系统做为能力开放平台来构建的时候，即类似互联网的OpenAPI平台构建，那么该系统就需要尽量不主动消费外部的服务接口，在这种情况下可能涉及到将服务设计为定时调用。

由于采用服务定时调用后，可能消费方无法第一时间获取到源系统的增量和变化数据，为了解决这个问题，我们可以统一设计一个消息通知服务，通过该服务将变化信息及时通知到目标系统，主要该服务类似一个通知广播，只告诉源数据数据有变化，而不会有任何实际的变化数据。这样做的目的仍然是提高在使用定时服务的场景提高数据同步的实时性。

对于定时调用的服务有几个重要，具体说明如下：

1. 定时调用服务原则是按照批量进行传递，即一次可以传递一批数据而不是单条数据，除非在数据量相当大的时候才会考虑对数据进行分页处理。对于每一个批量数据应该控制在一个事务里面。

2. 对于查询类定时调用服务，对于源数据库表必须要提供数据行的最后更新时间字段以作为判断增量的条件，对于新增数据可以将最后更新时间设置为和新增时间一致。

3. 对于定时调用的服务建议要在前台界面给业务管理员预留可以手工实时触发调用的入口，该功能可以由管理员手工实时触发调用，以解决在数据紧急需要同步时候的实时性问题。

对于实时调用的服务，前面场景分析也谈到了，既可以作为同步服务，也可以做为异步服务，关键是源业务系统有数据变化的时候能够实时触发服务调用即可。