集成模式是什么

多个系统要协作时，不能只靠「一个 Spring Boot 调另一个 HTTP」。企业集成模式（Enterprise Integration Patterns, EIP） 是一套经过验证的 通信与数据流转 方案——何时同步、何时发消息、如何容错、如何保持最终一致。

本 track 串联 spring-cloud-essentials、kafka-essentials、rabbitmq-essentials 的 架构视野，不重复讲安装与 API 细节。

学习目标

• 说清「集成」与「单体内部方法调用」的边界
• 列举分布式协作的三类典型挑战
• 对照 CodeRoadMap 当前单体与假想拆分后的差异

为什么需要集成模式

挑战	表现	模式方向
耦合	改 A 必改 B 的 DTO	消息、事件
可用性	下游挂导致全站超时	熔断、异步
一致性	跨库无法单事务	Saga、最终一致

单体里 @Transactional 能管住的边界，拆成微服务后要用 模式 + 基础设施 补回来。

典型集成拓扑

                    ┌──────────────┐
  客户端 ──────────►│  API Gateway │  ← spring-cloud-essentials
                    └──────┬───────┘
           ┌───────────────┼───────────────┐
           ▼               ▼               ▼
    order-service   inventory-service   notify-service
           │               │               │
           └─────── Kafka / RabbitMQ ──────┘  ← 本 track 重点

REST 适合 命令与查询；消息适合 通知与解耦。两者常并存，不是二选一。

与 REST 单体的边界

• 单体内部：Service 层方法调用，同一数据库事务
• 集成边界：进程间、团队间、发布节奏不同的模块之间
• 过度集成：把每个表都拆成微服务 + 全链路消息——见 ip-anti

CodeRoadMap 主站仍是单体 Spring Boot；读源码时标记「若这里是独立服务，会走哪种模式」。

本 track 路线图

1. 同步 vs 异步 → 消息 → 事件驱动
2. Saga、API 组合、BFF
3. 熔断、幂等、CQRS
4. 反模式与综合练习（订单-库存 Kafka 流）

练习

• 画一张「浏览器 → 网关 → 三服务 → MQ」示意图
• 列举本站 backend 里 2 处若拆分会用 HTTP 还是消息