集成方式的选择是架构决策
在企业信息化项目中，"用什么方式对接"经常被当作技术细节，交给开发人员随手决定。但这个选择会直接影响系统的耦合度、故障传播范围与后续的演进成本，是不折不扣的架构决策。
模式一：API 直连
A 系统同步调用 B 系统的接口，等待返回结果。
优点：实现直观，实时性好，调试方便。 代价：故障会直接传播。B 系统响应变慢，A 系统的线程池就会被占满，最终两个系统一起挂掉。
适用：查询类操作、对实时性要求高且调用方能接受失败的场景。比如下单前查询客户信用额度。
必备措施：超时设置、熔断降级、重试限制。没有这三样的 API 直连，是在给未来埋雷。
模式二：消息驱动
A 系统把事件发到消息队列，B 系统异步消费。
优点：解耦彻底，B 系统故障不影响 A 系统，天然支持削峰填谷。 代价：最终一致，需要处理消息重复、乱序与积压；调试链路变长。
适用：订单下推、状态回传等大多数写操作。这是我们在项目中的默认选择。
关键细节：消费端必须幂等。消息队列的"至少一次"投递保证意味着重复消费一定会发生，不是可能会发生。
模式三：数据库共享 / 中间表
A 系统写入约定的中间表，B 系统定时扫描处理。
优点：不需要 B 系统提供接口，对老旧系统友好。 代价：两个系统被数据库耦合死了。表结构一旦要改，双方必须同时发版。此外，直接读写对方数据库会绕过业务校验，很容易写入非法数据。
适用：目标系统完全封闭、没有任何 API 的历史遗留场景。属于不得已的选择。
风险控制：只用中间表，绝不直接读写对方业务表；中间表由集成方拥有，不属于任何一个业务系统。
模式四：文件交换
按约定格式生成 CSV/Excel，通过 FTP 或对象存储交换。
优点：技术门槛最低，跨组织跨网络都能用。 代价：实时性最差（通常 T+1），文件格式变更没有类型约束，错误往往在下游解析时才暴露。
适用：跨企业的批量数据交换、财务对账文件、监管报送。
一张决策表
| 场景 | 推荐模式 | 理由 |
|---|---|---|
| 实时查询额度 / 库存 | API 直连 + 熔断 | 需要即时结果 |
| 订单下推 ERP | 消息驱动 | 解耦，可重放 |
| 库存回传电商 | 消息驱动 + 定时兜底 | 实时 + 最终一致双保险 |
| 对接封闭老系统 | 中间表 | 无接口可用 |
| 跨企业对账 | 文件交换 | 批量、跨网络 |
无论哪种模式都要做的事
幂等键。每条数据带业务唯一键，重复处理不产生副作用。
同步状态可查。任何一条数据的同步状态、时间、失败原因都要能查到。运维最怕的不是失败，是不知道哪里失败了。
差异对账。每天定时比对两侧数据，输出差异清单。集成链路再健壮也会有意外，对账是兜底。
版本兼容。字段只增不删，删除字段前先确认无消费方。这一条在多方集成的项目里能省下无数次故障复盘。
最后
企业集成项目中，技术难度往往不是瓶颈，口径对齐才是。"什么算一笔有效订单""退货应该冲减哪个月的销量"——这类问题需要业务方拍板，而它们消耗的时间通常超过编码本身。
在项目排期时，请为口径讨论留出足够的时间。
