API同步轮询的目标与设计思想
在软件应用开发设计中，难免遇到需要和外部系统业务对接的场景，例如，内部订单系统需要对接支付宝接口已完成支付或者完善订单信息。其本质是，自身业务发生在企业体系之外，对应的重要的、必要的信息数据也源于体系外，自身应用需要同步外部数据，以保证自身业务正常进行。例如，跨境电商需要获取Amazon订单数据以完成后续的发货工作，获取Amazon财务数据以完成财务做账。
问题
我个人工作中便有相关经历，企业以人工的方式处理（各种Excel表、复制粘贴、计算器计算等方式）外部数据信息，代价是效率极低、出错率较高、人工成本高昂、职员的时间被耗费在重复的机械的无价值的事务中，销量越好，人力成本越高，成本和效益成线性相关。效率不增长，企业没发展，长此以往不可持续。
目标
“API同步轮询”即是上述问题的解决方案。其工作原理是，定期、定时访问第三方api接口，获取数据、同步到企业体系内部系统之中，并处理完成一定的业务，整个过程是全自动的，无人工干预。
设计要点
完整。数据表字段、结构设计必须符合自身业务，保证业务正常进行。
接续。每次轮询和上次轮询无缝对接，保证业务数据信息的完整，任何时间上的数据都不遗漏。
去重。已轮询过的数据，不可被二次加入；例如已经发货过的订单，再录入一次，造成发货和收款多了一次，而事实上只发生了一次。去重和接续实际上是同一个问题，良好的轮询方案必定既可接续，又能去重。
依赖。轮询之间彼此存在依赖关系，即某个轮询基于另一个轮询得到的数据。例如轮询订单明细有赖于订单数据，因此轮询得到订单数据后，订单明细轮询方可继续；再如，轮询财务明细有赖于财务账期数据，轮询得到账期信息后，方可继续轮询财务明细。
开发架构
单一。每个轮询的业务都应该极其简单，保持逻辑单一，业务简单，易组合调试。如果一项轮询中夹着另一项轮询，那么业务链条和代码逻辑有可能变得冗长、繁琐，易出错且不易维护。
隔离。各轮询之间彼此隔离、独自运行、互不干扰，存在依赖的轮询最多因为缺少所依赖的轮询数据而获取不到数据，并非自身轮询不运转，例如，没有订单号，并不意味着不执行“获取订单明细”任务。
容错。系统因各种原因出错、发生异常在所难免，各轮询应当结合各自应用场景的特征（包括日常使用频次、及时性等），定制自身的容错机制，以保证系统在暂停或者局部功能暂停重启后，轮询能够接续之前的数据正常运转，对依赖自己的轮询也不造成影响（最多只是延迟了数据的获取），最终整个系统依旧能够保持数据的完整和及时。
安全。轮询依赖于执行的记录，这些记录是轮询的安全基础。
来源：9PEAK
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！