这个话题来自网友提交和项目上真实的案例，即如何实现企业内部多个应用之间的数据交换。
这个话题非常实用，我们先从问题开始聊起（在很多系统设计的过程中，我们发现问题比答案有时候更有价值，因为问题贴合业务价值）。
问题
案例 1 业务和推荐系统集成
假设有两个系统，分别是 A 系统和 B 系统。A 系统是一个事务处理系统，而 B 系统则是一个算法和推荐系统。A 系统向 B 系统提供了一组数据，而 B 系统则根据主数据和业务数据生成了一份业务中间处理结果。
问题是：A、B 系统如何进行数据交换，以进行后续的业务处理？
案例 2 保单遗留系统迁移
某保险公司新开发了一套保单系统，业务部门希望实现渐进上线，也就是新旧系统并存。如何应对这一挑战？同时，我们需要考虑如何迁移数据以及保持数据同步，同时满足以下约束条件：
- 外部系统对接：新旧系统都需要与外部系统进行集成。
- 定时任务：新旧系统都包含定时任务。
- 数据共享：新旧系统需要能够访问并共享彼此的数据。
案例 3 业财一体化异步处理
某企业数字化转型，需要实现业财一体化，在这个过程中，其数据处理方式和传统的业务系统略有不同。
如何有效处理大量订单的周期性财务结算和对账，以确保准确性和效率？且同时满足以下关键要求：
- 大量数据处理：面对大量订单数据，如何高效地进行数据处理、清洗和整合，以便进行结算和对账操作？
- 数据溯源：如何追溯统计数据来源，并核对准确性。
- 数据工程成本：如何减少数据成本？
- 报告和洞察：如何生成有用的结算报告和数据可视化，以便管理层能够了解业务的财务状况和趋势？
案例 4 基础数据提取
某企业新创建的系统需要一些基础数据，这些基础数据来自于现有其它系统。例如，用户数据来自 IAM，品类数据来自于产品管理系统。
对于新创建的系统来说，如何使用企业内现有的基础数据？
常见解决方案
如何实现数据集成呢？根据经验，我们可能有常见方案:
下面逐个分析这些方案的利弊，以及适用场景。
共享数据库
共享数据库是一种直接的数据同步和共享的方案，顾名思义，直接访问对方数据库。其优点和缺点如下：
优点：
-
实时数据共享：共享数据库可以实现实时数据共享，多个系统可以立即访问和更新数据，确保数据的及时性。
-
数据一致性：由于所有系统使用的是同一个数据库，因此可以确保数据的一致性，减少了数据不一致的可能性。
-
简化开发和维护：相对于其他复杂的数据同步解决方案，共享数据库可能更容易实施和维护，尤其是在小型系统中。
缺点：
-
安全性风险：共享数据库可能导致安全性风险，因为多个系统都能够直接访问数据库。必须严格管理数据库的访问权限，以防止数据泄露或不当访问。
-
性能问题：多个系统同时访问数据库可能导致性能问题，特别是在高负载时，可能会降低数据库的性能（可以用从库解决这个问题）。
-
紧耦合：共享数据库会导致系统之间的紧耦合，如果一个系统的数据库结构发生变化，可能会影响其他系统的功能，增加了维护的复杂性。
-
难以扩展：共享数据库可能难以扩展到大规模系统，因为性能和一致性的问题可能会变得更加复杂。
在早期的项目中，共享数据库非常常见。但是由于多个团队都拥有数据访问权限和变更，会导致各种技术、管理上的问题，在业界已经不再推荐，同理也不推荐多个微服务直接共享数据库（权责利边界问题）。
不过，可以作为特殊场景下的权衡方案。
API 实时调用
API 实时调用一般是指使用 RESTFul 风格的 API 调用，是系统之间最常用的数据交换方式。
优点：
- 实时性：允许实时数据传输和更新。
- 灵活性：可适应各种数据格式和需求，且可以封装业务逻辑（最重要的一点）。
缺点：
- 维护成本：需要投入资源来开发和维护 API。
- 性能挑战：高频率 API 调用可能导致性能问题。
- 成本：需要成本来处理开发和维护。
- 同步：API 调用往往是同步进行的，如果需要改造成异步实现，需要额外成本。
对于少量、实时性要求高、封装有业务逻辑和动作的场景，可以使用 API 的方式交换数据。
MQ
和 API 类比的方案自然是 MQ，例如 Rabbit MQ 或 Kafka。
优点:
- 异步通信：MQ 支持异步通信，不需要实时等待响应，提高系统的可伸缩性和性能，以及可靠性。
- 消息重试：MQ 通常支持消息重试机制，以处理消息传递失败或处理失败的情况。
缺点：
- 复杂性：配置和管理 MQ 系统可能会比较复杂，特别是沟通文档，没有 API 友好。
- 错误处理：在处理消息传递失败或消息处理失败时，不好 Debug。
MQ 需要结合 API 使用，从维护和管理上来说，在应用之间集成尽量使用 API。
人工数据重新配置（例如 Excel 数据导入）
对于案例 4 的场景，很多企业会使用人工数据重新配置（直接拷贝过来用），例如使用 Excel 数据导入的方式，其实也是一种方案。
优点：
- 灵活性：用户可以根据需要手动配置和处理数据，适用于小规模的数据导入和处理任务。
- 成本低廉：不需要开发程序，适合一次性处理的场景。
- 业务再优化：在配置的过程可以对数据进一步清晰、整理（关键要素）。
缺点：
- 无法应对更新：对于需要频繁数据导入或大规模数据处理的任务，人工方法不切实际，难以扩展。
- 不适用于实时需求：无法满足需要实时或高频数据同步的场景，因为它是手动的过程。
很多人调侃企业信息系统的日常就是用户从一个系统导出 Excel 再导入另外一个系统，现代企业信息化改造和数字化转型就是解决这类问题。
让信息系统从能用到好用，再到一体化的过程，所以应该谨慎使用人工数据重新配置的方案。
使用 ETL 或 CDC 等数据同步平台
ETL（Extract, Transform, Load）和 CDC（Change Data Capture）都是数据同步和处理的技术，用于将数据从一个地方移动到另一个地方。
ETL 的关键步骤包括提取、转换、加载。CDC 可以视为 ETL 的一种，CDC 是一种用于捕获数据变更的技术（Mysql 基于 BinLog，PostgreSQL 基于 WAL），它关注的是源数据的变动，以便及时将这些变动同步到目标系统。
ETL 方案的特征是对应用透明的数据迁移，而 CDC 通常需要数据库支持。。
ETL 优点：
- 批处理处理：ETL 通常按批处理方式执行，适用于处理大量数据和定期数据同步需求。
- 数据转换和清洗：ETL 允许对数据进行复杂的转换、清洗和整合，以满足目标系统的需求，确保数据质量和一致性。
ETL 缺点：
- 延迟：由于是批处理，ETL 可能会导致一定的数据同步延迟，不适用于实时需求。
- 复杂：ETL 过程可能需要复杂的数据转换和处理逻辑，需要更多的开发和维护工作。
CDC 优点:
- 实时或近实时同步：CDC 可以捕获源数据的变更并实时或近实时地同步到目标系统，适用于需要快速反应的场景。
- 数据实时性：CDC 确保目标系统与源系统的数据保持同步，有助于提高数据的实时性。
CDC 缺点:
- 复杂：实时数据同步通常需要更多的技术和架构复杂性，需要具备相应的技术知识。
- 数据一致性：需要确保CDC过程的稳定性和数据一致性，避免数据丢失或冲突。
- 无法业务干预：无法在 CDC 传输过程中执行额外的业务逻辑，例如解析数据并做一些 API 查询，这点往往是 CDC 最致命的缺点。
ETL 和 CDC 都需要团队中有专业的数据工程师或者精通数据操作能力的人，前期投入成本比较高，但是平台搭建好后可以长期受益。
CDC 和 MQ 的方案有一些重叠，不过 MQ 更多的是指应用层面的消息发送，CDC 是通过 MQ 直接传输数据库变更。
MDM（主数据管理系统）
MDM 是主数据管理系统（MDM，Master Data Management）的英文缩写，它是一种用于集中管理和维护组织中关键的主数据的技术和方法。
主数据通常是指与业务操作和决策密切相关的核心数据，例如客户信息、产品数据、供应商信息。
MDM 系统通常有下面的特性：
- 数据收集和整合：MDM 系统从各个数据源（如 ERP 系统、CRM 系统、数据库等）收集主数据，并将其整合到一个集中的存储库中。
- 数据标准化：MDM 系统可用于标准化主数据，确保数据采用一致的格式和规范（关键要素）。
- 数据共享：MDM 系统允许多个应用程序和系统访问和共享相同的主数据，确保数据的一致性和可用性。
- 数据版本控制：MDM 系统允许记录和管理主数据的不同版本，以便跟踪和审计数据的变更历史。
MDM 非常适合案例 3 中的需求，有些 MDM 系统还搭配有小型的 ETL 能力，通过 Pull、Push 的方式集成企业内部基础数据。
优点：
- 数据一致性：MDM 系统确保主数据在整个组织中的一致性，避免了不同部门或系统中的数据不一致性。
- 数据集成：MDM 系统集成多个数据源，确保各系统使用的数据是同一版本的主数据，消除了数据孤岛问题。
缺点：
- 数据治理：MDM 系统需要强大的数据治理策略和流程，以确保数据的一致性和质量。
- 数据所有权：确定主数据的所有权和管理责任可能会引发组织内部的问题和争议。
- 适用范围：MDM 通常只适用于主数据管理，不进行 ETL、数据分析等能力，也不适用于业务数据集成。
MDM 的定位非常清晰，只做主数据管理，相比后面介绍的数仓相比同时具有轻量级的特点。
数仓
最后一个方案是数仓，也是最重的一个方案。数据仓库（Data Warehouse）是一个用于集中存储和管理组织内部各种数据的专用数据库系统。
数仓的常见特点：
- 数据整合：数据仓库从多个数据源（例如操作性数据库、日志文件、外部数据等）中提取数据，并将其整合到一个集中的存储库中。这确保了数据的一致性和可用性。
- 数据清洗和转换：数仓平台通常集成了 ETL，可以用于数据清洗、验证和转换，以确保数据的质量和一致性。
- 拓展性强：数仓架构中，通常会将数仓进行分区，包含 Staging、Marts 等区域。Marts 为数据集市，通过集市和消费数仓的数据对接，可以让数仓适用于几乎所有联机应用。
- 数据溯源：数仓可以通过对数据来源进行追溯，构建数据被加工前后的关联关系，实现对数据溯源（俗称血缘分析）。
数仓尤其适合处理案例 1 和案例 4 的问题，用于数据结果交换，主数据录入、提取、消费等场景。
当然，数仓的代价是比 ETL 更重，甚至需要一个专门的团队才能运转。
案例和方案总结
结合上面这些常见方案，我们对文章前的几个问题进行归纳。
案例 1 业务和推荐系统集成
可参考方案：
- 业务系统 ETL 进推荐系统，并通过 API 提供给前端输出推荐结果。
- 如有数仓使用数仓的 ETL，推荐系统使用数据集市完成。
设计原因：
- 推荐系统往往没有实时需求，ETL 是一个性价比不错的方案。
- 推荐系统可以作为独立的服务，能提供完整的推荐能力给前端，业务系统往往不需要再使用推荐结果。
案例 2 保单遗留系统迁移
可参考方案：
- 使用 ETL，但可以不用进仓，直接在新老系统之间交换数据。
设计原因：
- 不建议仅仅为了数据迁移而进仓，数据仓库是个中心化的系统，在其它业务系统无需消费的情况下无需使用过长的数据链路。
- 不建议使用 CDC，因为可能需要使用做一些业务映射，而不是单纯的数据同步。
案例 3 业财一体化异步处理
可参考方案：
- 如果需要实时触发结算动作，推荐使用 MQ 或者 Flink 等流计算平台。
- 如果不需要实时结算，可以使用 ETL 作业。
设计原因：
- 业务结算对结算时点敏感，T+1 作业可能不能满足需求，所以数仓通常不适合。
案例 4 基础数据提取
可参考方案：
- 如果已经有数仓平台和团队，优先使用数仓。
- 如果有 MDM 平台，可以使用 MDM 平台。
- 如果都没有，优先使用手动变更。
- 如果没有基础设施，业务希望自动更新，则可以使用定时任务通过 API 更新基础数据。
设计原因：
- 取决于基础设施，选择性价比合适的方案。
参考资料
[1] https://medium.com/@ramesh.esl/change-data-capture-cdc-in-postgresql-7dee2d467d1b
[2] https://datacater.io/blog/2021-09-02/postgresql-cdc-complete-guide.html
[3] https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-a-data-lake/#data-lake-vs-data-warehouse
[4] 部分内容参考使用了 ChatGPT 结果
-END-
文 | 少个分号 （转载请注明出处）
本文仅供学习！所有权归属原作者。侵删！文章来源： DDD和微服务 -shaogefenhao :http://mp.weixin.qq.com/s?__biz=MzA4Mzc2MzcyMQ==&mid=2247484954&idx=1&sn=becd19104293ad2fb8ec308412430d4f&chksm=9ff0317ca887b86ac8c8f6a446cfb910e599b9301bd053b34e49c3a4b3de0ebd7d848a1266ab&scene=21#wechat_redirect
文章评论