1. 服务间通信概述：单体架构 vs 微服务架构的通信挑战

1.1 单体架构下的通信：进程内调用

在单体架构中，所有业务模块（订单、支付、库存）运行在同一个操作系统进程中。模块之间的“通信”本质上是进程内方法调用（In-Process Call），通常表现为函数调用或本地接口引用。

• 调用方式：直接方法调用（Java 中的 orderService.createOrder()）。
• 通信成本：几乎为零，无网络开销、无序列化/反序列化。
• 可靠性：由编程语言运行时保证，不存在网络超时或连接断开。
• 治理复杂度：低，开发者无需关心协议、负载均衡或熔断。

1.2 微服务架构下的通信：网络级调用

当架构演进为微服务后，每个服务独立部署在各自进程中，服务间通信必须跨越网络边界。这带来了本质性的变化：

1.3 服务间通信的演进历史

从单体到微服务，服务间通信的治理经历了四个关键阶段：

1. 阶段一：点对点直连（2005-2010）——服务直接通过 HTTP/REST 或 RPC 调用对方地址，无注册中心、无负载均衡。问题：地址硬编码、单点故障、难以扩缩容。
2. 阶段二：服务注册与发现（2010-2014）——引入 ZooKeeper/Consul/Eureka，服务启动时注册，消费者通过 DNS 或客户端负载均衡调用。解决了地址管理问题，但协议和契约仍靠文档约定。
3. 阶段三：API 网关与统一入口（2014-2018）——网关层负责路由、限流、认证、协议转换。内部服务间通信开始标准化，但服务间直接调用仍缺乏契约约束。
4. 阶段四：基于契约的通信治理（2018-至今）——以 OpenAPI/Smithy/Protobuf 等 IDL 定义服务契约，通过契约驱动代码生成、测试、文档和版本管理。通信治理从“运维层面”上升到“架构设计层面”。

1.4 课程目标与学习路径

本课程旨在帮助架构师和技术负责人建立一套完整的服务间通信治理体系，核心目标如下：

• 目标一：掌握基于契约的 API 设计方法，能够使用 OpenAPI 3.x / Protobuf 定义服务边界和通信协议。
• 目标二：理解同步（REST/gRPC）与异步（事件/消息）通信模式的选型权衡，并能在架构设计中做出合理决策。
• 目标三：学会管理 API 版本演进，实现向后兼容的契约变更策略，避免“一改全崩”。
• 目标四：构建通信治理的工程化工具链——契约测试、Schema Registry、API 网关策略、可观测性集成。
• 目标五：通过真实案例（订单履约、支付链路）理解通信治理在架构演进中的落地实践。