企业系统数据集成模式
CRM 不知道 ERP 发了什么货，仓储系统不知道网店卖掉了什么。让系统对话就是数据集成，而其中最大的单一决策，是为每条连接选择什么模式。没有普适的最优——只有对每对系统、每个时效要求、每个故障预算而言的最合适。
三种基本模式
所有集成都是三个原型的变体。ETL（抽取-转换-加载）按调度批量搬数据：任务拉取、重塑、写入，隔夜或每小时一次。API 调用是同步的请求-响应：一个系统问另一个系统并等待。事件是异步的：一个系统发布一个事实，感兴趣的系统各自择机反应。ETL 最简单但数据陈旧；API 即时但调用方与被调方耦合；事件解耦但增加基础设施。
按需求配模式
- 每天变化的参考数据——隔夜 ETL 进数据仓库。够新鲜，也最简单。
- 录单时要确认"客户存在吗"——同步 API 调用；用户继续操作前必须拿到答案。
- "一张订单已下单"——用事件。库存、发货、分析各自反应，各按各的节奏，下单系统无需知道谁在听。
- 给监管机构的月报——批量 ETL 加校验；没人需要它更快，正确性胜过速度。
选型不是一次性的架构图。同一家公司的不同数据，合理地使用不同模式。
幂等不是可选项
网络会故障，消息会重复投递。若处理两次"订单已创建"就产生两次发货，集成迟早弄脏数据——不常发生，但总在最坏的时刻。让每个消费方幂等：记录已处理的消息 ID，或把处理器设计成重复同一事件是无操作（"置为已发货"，而非"发货数加一"）。这一条纪律消除了最令人畏惧的一类集成缺陷。
重试、死信与对账
失败的调用按指数退避加上限重试——猛打一个正在挣扎的系统只会放大故障。超限后把消息连同完整上下文停进死信队列并告警人工；静默丢失是不可原谅的失败。独立于这一切，定期跑对账：比对源端与目标端的记录数和校验和，在用户从报表里发现之前先暴露漂移。
事件契合主数据分发
回想主数据的规则：下游系统持有只读副本。事件是天然的载体：属主系统发布"客户已变更"，每个订阅方几秒内更新自己的副本。新系统加入只需订阅——不用导出表结构，不用点对点布线。治理数据的模式和搬运数据的模式，到头来是同一个决定。
每条连接端到端有主
集成腐烂最快的地方是接缝——"他们的系统"变成"你的问题"的那个交接点。给每条连接指定唯一负责人，端到端负责：运行手册、告警、对账结果、与厂商的沟通。凌晨两点 feed 断了，是负责人接听，而不是几个团队互相推诿。没有明确归属，集成会悄无声息地坏上几周，每个团队都以为另有人在看。
别为了优雅而统一成一种模式。宣布全靠事件的公司迟早发现：一个三天就能重建的夜间批处理，本可以完美服务好十几份报表。让模式贴合数据，不同的连接本就该长得不一样。
结语
要容忍度用 ETL，要即时性用 API，要解耦用事件——按连接选型，而非按公司选型。然后做那些决定一切能否活到生产的平凡工作：幂等消费、有界重试、死信队列与对账。管道可靠之后，才有可能自信地回答最难的那个问题——谁被允许看到这份数据。