架构分析与设计到实现的过程展示

一、需求

2017年底开始，有一个项目计划，建设云数据中心，然后基于数据开拓增值服务。

背景：略。

要建议云数据中心，第一个就是要先把源端的数据同步回来。源端就是第三方，向我们开放数据服务，我们可以根据我们的用户，把我们用户相关的信息从源端同步到云端。这种场景就好像是：开办信用卡的代理只能通过它的客户（信用卡申请人）授权，才能查看客户的信贷信息。

源端的主要约束，除了上述的外，还有：

1）  只能在每个月的16号到月底可以同步。

2）  每次只能同步一种数据（据源端方面的人所说，一种数据其实就是对应他们的一张表）。数据有700多种，也就是有700多个数据接口，分三类，A类有20多种数据，B类有10多种数据，C类有700多种数据。

3）  只接受我们的10个并发请求。

4）  都是日志类的数据，数据接口的每次调用必须设置时间标识。时间的跨度越大，返回的数据量就越大。

我们的主要约束（要求）：

1）  数据保存在公有云，数据库是MySQL。

2）  由于某种原因，我们必须采用定时任务方式同步数据。定时方式，我们又称为任务策略。

3）  不提供操作界面。

下面，就数据同步子系统的建设进行分析与设计。

二、分析与设计

1、  流程分析与设计：

1）初步分析与结果：

因为我们必须根据我们手上的用户信息，才能把源端的数据同步回来，因此，我们必须有个初始化步骤，把我们用户关键信息还有源端的数据种类导入来。接着，就是启动任务将数据同步回来，再将同步回来的数据根据数据种类不同而分开保存（也就是说，每个源端的数据种类，在云端都有一个对应的数据表）。流程是这样的：

每次不能同步太多的数据回来，因此，我们决定按数据类型、数据种类、时间标识分批将数据同步回来，另外，将原来一个流程拆分为初始化与数据同步（任务）两个流程。

初始化流程：

数据同步（任务）流程：

于是，得出粗略的第一个业务建模版本：

“签约用户”、“待同步数据种类列表”与“源数据获取”有关联，为了解耦，设计了一个新的业务对象“签约用户待同步数据”，也就是说，“签约用户待同步数据”是由“签约用户”和“待同步数据种类列表”组成。

“同步任务”是由“源数据获取”、“同步日志”、“任务策略”组成。

第一版业务建模：

设计第一版本的接口与交互：

数据初始化流程，在系统初始化时发生，也就是签约用户数据与源数据种类的数据导入，计划手工完成，因此不设计接口；并且，即使不是手工导入，也不考虑接口设计，只关注关键的部分，也就是通过数据同步任务将数据取回来，于是设计了数据同步任务相关接口与交互，如下图：

2）迭代一

根据上述的接口设计，再优化业务模型：

增加了“调用上下文”业务对象，使任务与数据保存解耦。如下图所示：

因为已经打算将“数据保存”从“任务”同解耦出来，不过，在流程设计中还没有体现出来，当然接口设计中也没有体现出来，于是，重新设计数据保存（任务）的流程与接口。

任务流程：

数据保存流程：

任务与数据保存接口设计与交互：

可以看到&#x