主要观点：

• 过去几年，出箱模式成为微服务间数据交换流的常见解决方案，能安全可靠地更新本地数据存储并发送通知，但也有变化和讨论。
• 出箱模式可确保本地数据库更新和消息发送的原子性，通过在数据库中插入通知消息到专门表，再由外箱中继异步发送到 Kafka，虽不提供完全的 ACID 事务保证，但提供最终一致性语义。
• 实现出箱模式有多种考虑因素，如轮询与基于日志的 CDC 对比（后者更好，能保证消息顺序和低延迟）、外箱表的结构和管理（需保证原子性和可移除已处理消息）、使用特定数据库函数存储消息到事务日志等，还需考虑消息格式和回补等问题。
• 出箱模式虽有目的和优势，但也有批评，如数据库开销（可通过日志式外箱缓解）、复杂性（从外部和内部角度看有不同看法，找到合适抽象可简化）、延迟（实际影响不大）等。
• 除出箱模式外还有其他替代方案，如 Dapr（有不同权衡）、Read-yourself（有缺点）、基于“原始”变更事件流的流处理（需添加流处理组件和处理事务语义）、2PC（虽类似但不会使出箱模式过时，会降低服务可用性等）、持久执行框架（前景有待观察）。

关键信息：

• 出箱模式在微服务数据交换中的作用和实现细节。
• 各种替代方案的特点和优缺点。
• 对出箱模式的批评及应对措施。

重要细节：

• 以 Oh-my-Dawg 为例说明出箱模式的应用场景和流程。
• 详细介绍轮询和基于日志的 CDC 的优缺点及区别。
• 阐述外箱表的结构和管理细节，如各列的作用。
• 提及不同数据库用于实现外箱模式的相关函数和存储引擎。
• 讨论消息格式的选择和 CloudEvents 的应用。
• 介绍回补的方法和相关算法。
• 分析出箱模式的各种批评及应对方式，如数据库开销的缓解方法、复杂性的内部视角简化等。
• 对比不同替代方案与出箱模式在各方面的差异。