API轮询同步架构 （Amazon API 二）

业务

架构是根据业务流程设计的，假定业务场景是拉取并更新Amazon的订单数据，如下图所示，是整个API轮询的业务流程，整个业务模块我们称之为“AmazonOrderSync”（亚马逊订单同步）。

 

流程图虽然包含了所有的业务逻辑和模块元素，但并未对它们归类，这使得我们在开发的逻辑里不得不包含所有的业务，逻辑复杂，耦合增大，难以维护和测试。我们将流程归类，如下图所示。

 

在细节上新流程与原先的并无差别，只是将其分割成3段：轮询接续“SyncInit”、Api模块“SyncStart”、数据更新“SyncEnd”，我们可以将它们打包成独立模块，并最终在业务“AmazonOrderSync”中调用。

 

 

方案

Laravel的任务调度提供了很好的解决方案：定时发起“AmazonOrderSync”业务，完成订单更新。拆分成3段业务，如下表。

字段	说明
SyncInit	业务发起端，获取最新的已完成的record，接续新增一条新的record，状态为“#1 发起”。
SyncStart	寻找最早的状态为“#1 发起”的record，根据其数据发起并获取api请求，成功后将record状态设置为“#2 已获取”， 并将获取数据缓存至record中。
SyncEnd	寻找最早的状态为“#2 已获取”的record，基于业务需求将更新数据，并将record状态设置为“#3 已完成”，业务结束。

 

方式A：3个任务

3段业务分别开发成3个任务，并且逆向依赖，任务3依赖任务2，任务2依赖任务1，Task设置好依赖关系，最终只需在总指令中调用任务3即可。

 

方式B：队列

3段业务顺序执行：任务1执行完毕，创建新队列执行任务2；任务2执行完毕，创建新队列执行任务3。

 

 

架构设计思想

无论是菜鸟程序员还是骨灰程序员，每次面对独立的类似上述的功能开发，都要花不少精力。那么，问题来了，有没有方法可以让任何程序员都可以轻松开始开发工作呢？答案是肯定的！为此，我们首先要做的是：设计构架。

首先，想象一下工业化的车间，流水线的作业被切分为多个环节，既有机器自动化的环节，也有人工作业的环节。而我们设计的构架正如车间的作业，并且，构架中尽可能多的实现及其自动化的部分（配置、初始化等），减少人工干预部分，因为人工干预的越多，bug也越多，代码也越难维护。

我们将整个架构分为4个模块：标准化流程、配置与初始化、自动化模块、自定义模块。

构架前，细致分析整个流程，固化并封装，任何新的“同步功能”都必须接入并遵循这套模式；不必人工参与的设计成自动化模块，新开发的功能，只需要做好“配置”即写完了一部分代码；每个功能具有独立的业务逻辑、截然不同的外部接口、不同的数据结构和存储方式，这些无法模式化的部分——需要“人工干预”的环节——即是开发人员主要的工作内容，在上文方案中，它们是“SyncStart”和“SyncEnd”；由于存在特殊业务，整个流程需要允许加入自定义的模块，以保证构架的灵活。