tongbu

基础数据同步方案及测试汇报

总体要求

xxx系统作为中心的一部分，担负运行中心的生产例会、项目评审、上线投产统计汇总等管理处理的工作。

xxx系统是独立部署、运行的系统，但要求其人员及组织架构的信息（简称基础数据）必须与ITIL系统一致，需要进行同步处理。

指导思想

Microsoft的主数据系统（简称主数据系统或MainData）主要负责统一化管理招行的基础数据，其信息与ITIL基本一致，且保持数据的同步。

由于网段访问限制等原因，驾驶舱不便或不能直接从ITIL获取数据；从沟通和需求方面的便利性考量，选择从MainData来做基础数据的同步更为简单容易。

因此，驾驶舱选择从MainData进行基础数据的同步。

驾驶舱采用集群部署架构，因此在同步数据时需要做集群的考虑。

 

技术解决方案

经过与Microsoft沟通了解：

1. MainData与ITIL之间的同步时间和频率为每天1次，时间为凌晨2点左右；

2. MainData组织结构层次复杂，记录中的组织全名为该组织层次路径；

3. MainData人员信息中包含其所在组织的全名；

4. MainData对外提供了查询人员/组织等WebService接口；

5. 总数据量比较大。

 

驾驶舱同步方案设计：

1. 采用调用WebService方式获取有变更的基础信息；

2. 每天凌晨同步1次，时间在MainData之后的4点；

3. 只关注“招商银行/总行/信息技术部”及其子孙组织的组织和人员，其余一律放弃同步；

4. 可通过界面触发同步（单条记录或批量同步）；

5. 包含失败重新尝试的保障机制（3次机会尝试）；

6. 只关注“信息技术部”， 缩减组织结构，但保存全名；

7. 采用调度方式进行同步，分变更数据（上一次同步时间之后变更的数据）和失败重试两个任务进行；

8. 设计开关控制，可对调度任务进行启用或停用。

 

在实现技术上，引入开源Quartz调度框架，灵活配置调度频率及时间；考虑到驾驶舱采用集群部署方式，有4个实例同时在运行，因此要解决调度中的集群问题必须采取持久化Task任务才可以解决集群重复调度的问题。

驾驶舱每次调用SSO接口都将调用情况作为日志记录入表，采用异步形式去保存日志，提升接口响应速度。

开发实现注意点：MainData提供WebService接口为根据更新时间（ModTime）进行查询获取人员账户信息，如果调用的时间参数控制不好，可能会导致提取过多数据而导致内存溢出而失败；因此，必须要记录上一次同步的时间，作为下次同步查询入参。

 

同步调度方案（变更同步与失败重试两个调度方案）流程设计图：

 

重试调度机制的调度时间变更同步机制之后一个小时，即凌晨5点，5-6点之间每15分钟检查一次。

同步失败的记录收集入DB表，提供给重试调度机制再次去做调用，同时限制最大尝试次数为3次。

 

测试结果

每次成功调用之后都会更新本次同步的时间，因而可通过WebService接口获取变更的记录，达到只关注变更的记录。

下图为调度任务的开关及最后同步时间配置记录：

 

如果先前存在失败的同步记录，则重试调度机制会再次去尝试调用，并更新结果。如图为失败的记录，并在重试之后成功的结果图：