API同步轮询的目标与设计思想 （Amazon API 一）

API同步轮询的目标与设计思想

在软件应用开发设计中，难免遇到需要和外部系统业务对接的场景，例如，内部订单系统需要对接支付宝接口已完成支付或者完善订单信息。其本质是，自身业务发生在企业体系之外，对应的重要的、必要的信息数据也源于体系外，自身应用需要同步外部数据，以保证自身业务正常进行。例如，跨境电商需要获取Amazon订单数据以完成后续的发货工作，获取Amazon财务数据以完成财务做账。

问题

我个人工作中便有相关经历，企业以人工的方式处理（各种Excel表、复制粘贴、计算器计算等方式）外部数据信息，代价是效率极低、出错率较高、人工成本高昂、职员的时间被耗费在重复的机械的无价值的事务中，销量越好，人力成本越高，成本和效益成线性相关。效率不增长，企业没发展，长此以往不可持续。

目标

“API同步轮询”即是上述问题的解决方案。其工作原理是，定期、定时访问第三方api接口，获取数据、同步到企业体系内部系统之中，并处理完成一定的业务，整个过程是全自动的，无人工干预。

设计要点

完整。数据表字段、结构设计必须符合自身业务，保证业务正常进行。

接续。每次轮询和上次轮询无缝对接，保证业务数据信息的完整，任何时间上的数据都不遗漏。

去重。已轮询过的数据，不可被二次加入；例如已经发货过的订单，再录入一次，造成发货和收款多了一次，而事实上只发生了一次。去重和接续实际上是同一个问题，良好的轮询方案必定既可接续，又能去重。

依赖。轮询之间彼此存在依赖关系，即某个轮询基于另一个轮询得到的数据。例如轮询订单明细有赖于订单数据，因此轮询得到订单数据后，订单明细轮询方可继续；再如，轮询财务明细有赖于财务账期数据，轮询得到账期信息后，方可继续轮询财务明细。

开发架构

单一。每个轮询的业务都应该极其简单，保持逻辑单一，业务简单，易组合调试。如果一项轮询中夹着另一项轮询，那么业务链条和代码逻辑有可能变得冗长、繁琐，易出错且不易维护。

隔离。各轮询之间彼此隔离、独自运行、互不干扰，存在依赖的轮询最多因为缺少所依赖的轮询数据而获取不到数据，并非自身轮询不运转，例如，没有订单号，并不意味着不执行“获取订单明细”任务。

容错。系统因各种原因出错、发生异常在所难免，各轮询应当结合各自应用场景的特征（包括日常使用频次、及时性等），定制自身的容错机制，以保证系统在暂停或者局部功能暂停重启后，轮询能够接续之前的数据正常运转，对依赖自己的轮询也不造成影响（最多只是延迟了数据的获取），最终整个系统依旧能够保持数据的完整和及时。

安全。 轮询依赖于执行的记录，这些记录是轮询的安全基础。