1. 微服务通信基础
微服务通信是分布式系统设计的核心议题。从单体架构向微服务架构演进时，服务间的交互方式、协议选择与通信模式直接决定了系统的性能、可维护性与扩展性。本节从架构对比出发，逐步深入同步/异步通信、REST vs gRPC 的差异，并总结服务间通信的核心挑战。
1.1 单体架构 vs 微服务架构
单体架构将所有功能模块打包在同一个进程中运行，而微服务架构将系统拆分为多个独立部署的服务。两者在通信方式上存在本质区别。
| 维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 通信方式 | 函数调用 / 本地方法调用 | 网络 IPC（HTTP、gRPC、消息队列） |
| 延迟 | 纳秒级（内存内） | 毫秒级（网络开销） |
| 耦合度 | 高（共享数据库、共享代码） | 低（独立数据存储、独立部署） |
| 扩展性 | 整体垂直扩展 | 按服务水平扩展 |
| 故障隔离 | 单点故障影响全局 | 故障被限制在单个服务内 |
| 技术栈 | 单一语言/框架 | 多语言、多协议 |
关键洞察： 微服务架构将“函数调用”转变为“网络通信”，这是性能优化的起点。每一次跨服务调用都意味着序列化、网络传输、反序列化的开销，必须通过协议选择、连接复用、批量处理等手段来压缩。
1.2 同步通信与异步通信
服务间通信模式主要分为同步与异步两大类。选择哪种模式直接影响系统的响应时间、吞吐量和容错能力。
- 同步通信： 调用方发送请求后阻塞等待响应，直到收到应答或超时。典型实现：HTTP/REST、gRPC 一元调用。
- 异步通信： 调用方发送请求后立即返回，不等待响应；通过回调、事件或消息队列处理结果。典型实现：消息队列（Kafka、RabbitMQ）、gRPC 流式调用、事件驱动架构。
| 对比维度 | 同步通信 | 异步通信 |
|---|---|---|
| 调用方阻塞 | 是，等待响应 | 否，立即返回 |
| 延迟敏感度 | 高，受下游服务影响 | 低，调用方不受下游延迟影响 |
| 吞吐量 | 受限于线程/连接数 | 高，可批量处理 |
| 错误处理 | 即时返回错误码/异常 | 需要补偿机制、死信队列 |
| 典型场景 | 实时查询、用户交互 | 日志收集、事件通知、数据同步 |
| Go 实现 | goroutine + channel 阻塞 | goroutine + 消息队列客户端 |
实践建议： 在微服务架构中，核心业务链路（如订单创建、支付）通常使用同步通信保证数据一致性；非核心链路（如日志、通知、分析）优先采用异步通信降低耦合。gRPC 同时支持一元调用（同步）和服务器/客户端/双向流（异步），为混合模式提供了统一协议基础。
1.3 REST 与 gRPC 对比
REST 和 gRPC 是微服务通信中最常用的两种协议。REST 基于 HTTP/1.1 + JSON，gRPC 基于 HTTP/2 + Protobuf。两者在设计哲学、性能、生态上存在显著差异。
| 对比维度 | REST (HTTP/1.1 + JSON) | gRPC (HTTP/2 + Protobuf) |
|---|---|---|
| 传输协议 | HTTP/1.1（通常） | HTTP/2（强制） |
| 数据格式 | JSON（文本，可读性强） | Protobuf（二进制，体积小） |
| 序列化速度 | 较慢（反射 + 文本解析） | 极快（代码生成 + 二进制编码） |
| 消息体积 | 大（含冗余字段名） | 小（字段编号映射） |
| 流式支持 | SSE / WebSocket（非原生） | 原生支持（一元、服务器流、客户端流、双向流） |
| 接口定义 | OpenAPI / Swagger（文档驱动） | Proto 文件（代码生成驱动） |
| 浏览器支持 | 原生支持 | 需要 gRPC-Web 代理 |
| 性能（吞吐量） | 较低（文本解析 + 连接开销） | 高（连接复用 + 二进制帧） |
性能数据参考： 在同等硬件条件下，gRPC 的吞吐量通常是 REST/JSON 的 5~10 倍，消息体积减少 60%~80%。对于高并发、低延迟的微服务场景，gRPC 是更优的选择。Go 语言对 HTTP/2 和 Protobuf 的原生支持，使得 gRPC 在 Go 生态中成为事实标准。
1.4 服务间通信挑战
微服务架构将单体内的函数调用转变为网络通信，引入了一系列新的挑战。理解这些挑战是进行通信优化的前提。
- 网络延迟与不可靠性： 每次跨服务调用都涉及网络往返，延迟从纳秒级上升到毫秒级。网络分区、丢包、超时是常态。
- 序列化与反序列化开销： 数据需要在传输前编码、接收后解码。格式选择（JSON vs Protobuf）直接影响 CPU 消耗和延迟。
- 连接管理： 大量服务实例间需要维护 TCP 连接。连接池大小、复用策略、健康检查直接影响资源占用和请求成功率。
- 服务发现与负载均衡： 服务实例动态扩缩，调用方需要实时获取可用实例列表并分发请求。错误的负载均衡策略会导致热点或雪崩。
- 容错与重试： 网络故障、服务过载、慢响应需要熔断、限流、重试等机制。重试风暴可能放大故障。
- 协议兼容性： 服务独立演进，接口版本管理、字段兼容性（向后/向前兼容）是持续挑战。Protobuf 的字段编号机制天然支持兼容性。
- 观测性： 分布式调用链追踪、指标收集、日志聚合在微服务中比单体复杂得多。每个跨服务调用都需要注入上下文（trace ID、span ID）。
常见陷阱： 很多团队在微服务初期忽略通信开销，直接使用 REST/JSON 进行高频调用，导致延迟飙升。另一个常见问题是重试策略不当——没有指数退避和 jitter，导致下游服务在故障恢复时被重试请求冲垮。gRPC 内置了重试策略和截止时间（deadline）机制，可以有效缓解这些问题。