我们建立一个数字化系统可能会有跟别的系统进行数据对接的需要，而别人的数字化系统也有可能需要跟我们的系统进行数据对接，也可能我们开发了不同的网站，网站小应用之间需要进行数据对接。那么数据对接应该如何操作呢？怎么才能更好地做好数据的同步？跨系统数据一致性问题怎么解决？本文旨在总结沉淀工作中问题的解决经验，通过统一的轻易云数据集成平台整理解决跨系统数据不一致问题的经验方法。一、解决跨系统间数据一致性的难题提到数据一致性，我们很容易想到的就是数据库中的事务操作。事务的原子性和持久性可以确保在一个事务内，操作多条数据，要么都成功，要么都失败。这样在一个系统内部，我们可以很自然地使用数据库事务来保证数据一致性。但是在微服务的今天，一项操作会涉及到跨多个系统多个数据库的时候，用单一的数据库事务就没办法解决了。另外常见的一种情况就是：存在依赖情况的系统服务，例如业务端与用户端（业务端负责生产数据，用户端负责展示数据），需要数据同步来保障跨系统服务的数据一致性，很多时候采用何种数据同步方式，来保障数据应用的时效性至关重要。做数据对接需要考虑一个是单向数据对接还是双向的数据对接，如果是单向的数据对接我们只需要考虑去获取数据，也就是从目标数字化系统或是其它数字化系统从我们数字化系统上获取数据，我们通过API进行获取或是传输数据给对方。如果是我们数字化系统上注册的会员数据需要同步给对方，对方那边注册的会员数据，修改的会员资料也需要同步过来，做到数据双方的实时更新，这个就是做数据的双向对接了。不仅我们需要传输数据过去，对方也需要传输数据给我们，不过这个不需要我们提供API接口给对方，对方也提供API接口给我们，只需要一方的API接口实现数据的获取跟传输就可以了。这种数据的双向对接会用在很多的平台上，我们在进行对接的时候也要考虑我们需要的是数据的获取就可以，还是还需要把数据传送过去。如果是需要做到双向对接，而我们只考虑单向对接的话，数据就会出现问题。比如对方那边注册的会员数据同步给我们了，但是我们这边注册的会员数据没同步过去，客户就无法在对方数字化系统上登录使用。二、一致性的难题的分析为了能够更好的描述与理解数据一致性问题，通过一个案例来实战阐述：假设存在订单系统与库存系统，分别是金蝶云ERP与一款WMS系统之间需要进行数据对接，在实际业务中订单的创建会伴随着系统仓库模块的库存减少。两个系统为分别部署，其应用数据也存放在独立的数据库中，两个系统间通过网络API接口进行通信。如何做数据对接呢，这个主要是通过API进行的，也就是提供数据方编写接口文档，告知对接方应该通过哪一些的字段什么样的形式进行数据的获取。进行数字化系统搭建数据对接时不仅仅要考虑数据的获取，也要考虑到数据的传输，具体要用什么样的形式要看双方对于数据的要求。如果是不仅需要获取也需要传输的，就要将这方面的数据对接考虑上，不然对接之后，数据会出现问题，这个是一个主要注意的点。其它的，只要是有API接口，对接就基本不会有什么问题。 2.1、数据集成平台 CAP 原则 CAP 之间本身就是处于互斥的，只能从这三者中选两个处理，对于 CA、AP、CP 都有它们自己的应用场景，要结合实际进行选择。 CA 因为不考虑分区容忍度，所以它的所有操作需要在同一进程内完成（也就是我们常说的单体应用）； AP 因为放弃数据一致性，适合数据要求不高但强调用户体验的项目，如博客、新闻资讯等； CP 反之放弃了可用性，适合数据要求很高的交易系统，如银行交易、电商的订单交易等，就算是用户长时间等待，也要保障数据的完整可靠。 CAP 原则在实际项目中的运用，对于互联网应用来说，如果为了用户体验完全放弃数据一致性这也是不可取的，毕竟数据才是应用的根本。数据集成平台需要如何解决CAP互斥性呢？保障最终一致性的措施有很多，主要包括：分布式事务和 TCC 一致性方案。MySQL 其实有一个两阶段提交的分布式事务方案（MySQL XA），但是该方案存在严重的性能问题。比如，一个数据库的事务与多个数据库之间的 XA 事务性能可能相差 10 倍。另外，在 XA 的事务处理过程中它会长期占用锁资源，所以一开始我们并不考虑这个方案。三、高可用的系统数据同步方案实践问题描述：还是回到之前的数据集成案例场景，数据需要从金蝶云星空系统同步到旺店通系统。订单系统同步到库存系统中。解决数据一致性常用的三类数据同步方案：实时同步、定时同步、手动同步。数据集成平台设计核心特性： • 实时数据集成API统一管理 • 可视化的配置工具 • 实现低代码集成方案 • 非入侵式 • 松耦合集成 • 不侵入现有业务系统 • 敏捷交付开箱即用 • 丰富的场景化集成方案采用异步协程架构模式设计的数据集成平台，通过Message Queue（MQ），消息队列中间件。MQ 通过将消息的发送和接收分离来实现应用程序的异步和解偶，同时 MQ 屏蔽底层复杂的通讯协议，定义了一套应用层的、更加简单的通讯协议。在业务系统设计中，我们常常会存在一个平台系统金蝶，它关联同步了许许多多的系统的对接（系统聚水潭、泛微、MES 等）。利用 MQ 可以很好的解决系统对接和数据同步问题，同时可以忽略对接系统的稳定性等诉求。任务调度者 • 调度事件 • 生产任务 • 调度任务池-异步 AsynDispatcher --source 实例化适配器执行 • 消费任务 • 实例化集成应用 DataHub Instance handleSourceDispatch() • 依赖注入集成方案适配器 • 调度条件检查 • 执行适配器调度方法 • 联动其它方案调度任务 SourceEvent 适配器调度周期 • 初始化变量 • 根据元数据配置生成请求参数 • 向源队列存储器写入任务=>JobId • 生产任务 • 方案任务队列池-异步租户进程实例化适配器执行 • 实例化集成应用 DataHub Instance handleSourceJob() • 根据任务id定位找到mongodb中对应的任务详情 JobId=>findSourceJob • 执行适配器内SDK Adapter->SDK->invoke() 触发事件加工厂 • 事件加工厂 ScriptFactory::AfterSourceInvoke 适配器处理响应-success • 处理响应数据 handleResponse • 判断接口请求任务成功/失败 • 定位 Response 数据Key • 遍历数据对象，Mongodb 存储对象 • 标记任务状态 Finished • 提供InvokeRequest 进行分页查询任务适配器处理任务错误 • Throwable 异常搜集器 • 标记任务状态 Error • 任务重试机制 ReQueue()

如何实现高质量的系统数据对接/API接口整合集成方案？

轻易云

我们建立一个数字化系统可能会有跟别的系统进行数据对接的需要，而别人的数字化系统也有可能需要跟我们的系统进行数据对接，也可能我们开发了不同的网站，网站小应用之间需要进行数据对接。那么数据对接应该如何操作呢？怎么才能更好地做好数据的同步？跨系统数据一致性问题怎么解决？本文旨在总结沉淀工作中问题的解决经验，通过统一的轻易云数据集成平台整理解决跨系统数据不一致问题的经验方法。

一、解决跨系统间数据一致性的难题

提到数据一致性，我们很容易想到的就是数据库中的事务操作。事务的原子性和持久性可以确保在一个事务内，操作多条数据，要么都成功，要么都失败。这样在一个系统内部，我们可以很自然地使用数据库事务来保证数据一致性。但是在微服务的今天，一项操作会涉及到跨多个系统多个数据库的时候，用单一的数据库事务就没办法解决了。另外常见的一种情况就是：存在依赖情况的系统服务，例如业务端与用户端（业务端负责生产数据，用户端负责展示数据），需要数据同步来保障跨系统服务的数据一致性，很多时候采用何种数据同步方式，来保障数据应用的时效性至关重要。

做数据对接需要考虑一个是单向数据对接还是双向的数据对接，如果是单向的数据对接我们只需要考虑去获取数据，也就是从目标数字化系统或是其它数字化系统从我们数字化系统上获取数据，我们通过API进行获取或是传输数据给对方。如果是我们数字化系统上注册的会员数据需要同步给对方，对方那边注册的会员数据，修改的会员资料也需要同步过来，做到数据双方的实时更新，这个就是做数据的双向对接了。不仅我们需要传输数据过去，对方也需要传输数据给我们，不过这个不需要我们提供API接口给对方，对方也提供API接口给我们，只需要一方的API接口实现数据的获取跟传输就可以了。这种数据的双向对接会用在很多的平台上，我们在进行对接的时候也要考虑我们需要的是数据的获取就可以，还是还需要把数据传送过去。如果是需要做到双向对接，而我们只考虑单向对接的话，数据就会出现问题。比如对方那边注册的会员数据同步给我们了，但是我们这边注册的会员数据没同步过去，客户就无法在对方数字化系统上登录使用。

二、一致性的难题的分析

为了能够更好的描述与理解数据一致性问题，通过一个案例来实战阐述：

假设存在订单系统与库存系统，分别是金蝶云ERP与一款WMS系统之间需要进行数据对接，在实际业务中订单的创建会伴随着系统仓库模块的库存减少。两个系统为分别部署，其应用数据也存放在独立的数据库中，两个系统间通过网络API接口进行通信。

如何做数据对接呢，这个主要是通过API进行的，也就是提供数据方编写接口文档，告知对接方应该通过哪一些的字段什么样的形式进行数据的获取。进行数字化系统搭建数据对接时不仅仅要考虑数据的获取，也要考虑到数据的传输，具体要用什么样的形式要看双方对于数据的要求。如果是不仅需要获取也需要传输的，就要将这方面的数据对接考虑上，不然对接之后，数据会出现问题，这个是一个主要注意的点。其它的，只要是有API接口，对接就基本不会有什么问题。

2.1、数据集成平台 CAP 原则

CAP 之间本身就是处于互斥的，只能从这三者中选两个处理，对于 CA、AP、CP 都有它们自己的应用场景，要结合实际进行选择。

CA 因为不考虑分区容忍度，所以它的所有操作需要在同一进程内完成（也就是我们常说的单体应用）；
AP 因为放弃数据一致性，适合数据要求不高但强调用户体验的项目，如博客、新闻资讯等；
CP 反之放弃了可用性，适合数据要求很高的交易系统，如银行交易、电商的订单交易等，就算是用户长时间等待，也要保障数据的完整可靠。
CAP 原则在实际项目中的运用，对于互联网应用来说，如果为了用户体验完全放弃数据一致性这也是不可取的，毕竟数据才是应用的根本。
数据集成平台需要如何解决CAP互斥性呢？
保障最终一致性的措施有很多，主要包括：分布式事务和 TCC 一致性方案。MySQL 其实有一个两阶段提交的分布式事务方案（MySQL XA），但是该方案存在严重的性能问题。

比如，一个数据库的事务与多个数据库之间的 XA 事务性能可能相差 10 倍。另外，在 XA 的事务处理过程中它会长期占用锁资源，所以一开始我们并不考虑这个方案。

三、高可用的系统数据同步方案实践

问题描述：还是回到之前的数据集成案例场景，数据需要从金蝶云星空系统同步到旺店通系统。订单系统同步到库存系统中。
解决数据一致性常用的三类数据同步方案：实时同步、定时同步、手动同步。数据集成平台设计核心特性：
• 实时数据集成API统一管理
• 可视化的配置工具
• 实现低代码集成方案
• 非入侵式
• 松耦合集成
• 不侵入现有业务系统
• 敏捷交付开箱即用
• 丰富的场景化集成方案

采用异步协程架构模式设计的数据集成平台，通过Message Queue（MQ），消息队列中间件。MQ 通过将消息的发送和接收分离来实现应用程序的异步和解偶，同时 MQ 屏蔽底层复杂的通讯协议，定义了一套应用层的、更加简单的通讯协议。在业务系统设计中，我们常常会存在一个平台系统金蝶，它关联同步了许许多多的系统的对接（系统聚水潭、泛微、MES 等）。利用 MQ 可以很好的解决系统对接和数据同步问题，同时可以忽略对接系统的稳定性等诉求。

任务调度者

• 调度事件
• 生产任务
• 调度任务池-异步 AsynDispatcher --source

实例化适配器执行

• 消费任务
• 实例化集成应用 DataHub Instance handleSourceDispatch()
• 依赖注入集成方案适配器
• 调度条件检查
• 执行适配器调度方法
• 联动其它方案调度任务 SourceEvent

适配器调度周期

• 初始化变量
• 根据元数据配置生成请求参数
• 向源队列存储器写入任务=>JobId
• 生产任务
• 方案任务队列池-异步 租户进程

实例化适配器执行

• 实例化集成应用 DataHub Instance handleSourceJob()
• 根据任务id定位找到mongodb中对应的任务详情 JobId=>findSourceJob
• 执行适配器内SDK Adapter->SDK->invoke()

触发事件加工厂

• 事件加工厂 ScriptFactory::AfterSourceInvoke

适配器处理响应-success

• 处理响应数据  handleResponse
• 判断接口请求任务成功/失败
• 定位 Response 数据Key
• 遍历数据对象，Mongodb 存储对象
• 标记任务状态 Finished
• 提供InvokeRequest 进行分页查询任务

适配器处理任务错误

• Throwable 异常搜集器
• 标记任务状态 Error
• 任务重试机制 ReQueue()