从最简单的定时轮询到事件驱动，6 种模式的适用场景、复杂度和我们踩过的坑。
选错模式的代价
集成方案选错，通常不会立刻出问题，而是在半年后以「数据老是不同步」或者「接口限流把服务打挂」的形式爆发。
下面按复杂度递增排列 6 种常见模式，以及各自该在什么场景下用。
1. 定时轮询（Scheduled Polling）
最简单的方案：定时任务周期性拉取全量或增量数据。
适用场景：数据量小、实时性要求低（小时级或天级）、对方接口不支持增量查询。注意加上增量时间戳，否则数据量一大就会拖垮双方。
2. Webhook 回调
对方在事件发生时主动推送。实时性好，但要求你有公网可访问且高可用的接收端点。
必做三件事：签名验证、幂等处理、失败重试队列。漏掉幂等，网络抖动导致的重复推送会让数据翻倍。
3. 消息队列中转
把接收到的事件先落队列，再由消费者异步处理。适合削峰和保证不丢消息。
适合：流量波动大、下游处理耗时、或者需要重放历史事件。代价是运维复杂度上升。
4. 变更数据捕获（CDC）
直接监听数据库层面的变更日志，而不是依赖应用层发事件。
适合：需要同步老系统、对方不提供 API、或者要保证「不漏任何变更」。它对源库的侵入性最低，但对运维要求最高。
5. 聚合层 / BFF
在多个上游系统之上加一层聚合，对下游暴露统一的接口和模型。
适合：需要同时对接 3 个以上系统、或者上游系统随时可能替换。这一层的核心价值是隔离变化——上游换了，下游不用改。
6. 事件驱动架构
所有系统通过事件总线通信，彼此不直接调用。
这是长期最灵活、也是初期最贵的方案。只有在系统数量多、团队独立部署、且业务确实需要时才值得。不要为了架构先进性而提前引入。
我们的选型顺序
默认从最简单的方案开始，只有当它明确不满足需求时才升级。轮询能解决的，不要上 webhook；webhook 能解决的，不要上消息队列。每升一级，运维负担大约翻一倍。
一个通用建议
无论选哪种模式，都要在系统里保留一份「同步日志」：什么时间、同步了什么、成功还是失败、失败原因是什么。当业务方问「这笔数据为什么没同步」时，这张表能省掉你两小时的排查。