1. 微服务通信概述
微服务架构的核心在于将单体应用拆分为多个独立部署、自治运行的服务实例。这些服务实例必须通过某种通信机制协同工作，才能完成完整的业务逻辑。通信方式的选择直接影响系统的耦合度、性能、可用性和可维护性。本节从同步与异步通信模式对比、REST 与 gRPC 核心差异、以及微服务链路中通信的挑战三个维度展开，为后续深入探讨 gRPC 重试机制奠定基础。
1.1 同步与异步通信模式对比
在微服务链路中，服务间通信模式主要分为同步通信和异步通信两大类。同步通信要求调用方在发出请求后阻塞等待响应，直到被调用方返回结果或超时；异步通信则允许调用方发出请求后立即返回，不等待响应，通过回调、消息队列或事件驱动机制获取结果。
| 对比维度 | 同步通信 | 异步通信 |
|---|---|---|
| 调用模型 | 请求-响应，调用方阻塞等待 | 事件驱动/消息传递，调用方非阻塞 |
| 典型协议 | HTTP/REST、gRPC（Unary） | Kafka、RabbitMQ、gRPC（Stream） |
| 耦合度 | 时间耦合（双方必须同时在线） | 时间解耦（通过中间件缓冲） |
| 链路追踪 | 天然支持请求-响应追踪 | 需要额外关联 ID 传递 |
| 失败处理 | 即时失败，需重试或熔断 | 消息持久化，可延迟重试 |
| 适用场景 | 实时查询、强一致性操作 | 事件通知、最终一致性、削峰填谷 |
实践建议：在微服务链路中，核心业务链路（如订单创建、支付扣款）通常采用同步通信以保证实时性和一致性；而非核心链路（如日志记录、通知推送）适合异步通信，降低主链路延迟和故障影响范围。
1.2 REST 与 gRPC 核心差异
REST（Representational State Transfer）和 gRPC（gRPC Remote Procedure Call）是微服务通信中最具代表性的两种协议。REST 基于 HTTP/1.1，以资源为中心，使用 JSON/XML 文本格式；gRPC 基于 HTTP/2，以服务/方法为中心，使用 Protocol Buffers 二进制序列化。两者在设计哲学、性能、生态支持上存在显著差异。
| 对比维度 | REST (HTTP/JSON) | gRPC (HTTP/2 + Protobuf) |
|---|---|---|
| 传输协议 | HTTP/1.1（通常） | HTTP/2（强制） |
| 数据格式 | JSON / XML（文本，可读性强） | Protocol Buffers（二进制，体积小） |
| 接口定义 | OpenAPI / Swagger（文档驱动） | .proto 文件（契约驱动，代码生成） |
| 流式支持 | SSE / WebSocket（非原生） | 原生支持 Unary、Server/Client/Bidirectional Streaming |
| 序列化性能 | 较慢（JSON 解析开销大） | 极快（二进制编码，零拷贝可选） |
| 浏览器兼容 | 原生支持 | 需 gRPC-Web 代理 |
| 重试机制 | 需自行实现（如拦截器） | 内置 Retry Policy（状态码驱动） |
关键结论：gRPC 在微服务内部链路通信中具有明显优势——更低的延迟、更小的网络带宽占用、强类型契约和原生流式支持。REST 更适合对外 API 网关、浏览器端和需要人类可读调试的场景。本课程后续章节将重点围绕 gRPC 的重试机制展开。
1.3 微服务链路中通信的挑战
在微服务链路中，一个业务请求往往需要跨越多个服务节点（例如：API 网关 → 用户服务 → 订单服务 → 库存服务 → 支付服务）。这种分布式调用链引入了单体架构中不存在的通信挑战，主要体现在以下几个方面：
- 网络不可靠性：服务间通信依赖网络，丢包、延迟抖动、连接重置、DNS 解析失败等网络故障是常态，而非异常。
- 部分失败（Partial Failure）：链路上某个服务实例可能因过载、内存溢出、死锁等原因无法正常响应，导致整个调用链阻塞或超时。
- 级联故障（Cascading Failure）：一个服务的延迟或失败可能通过同步调用向上游传播，最终导致整个系统雪崩。
- 超时与重试风暴：不合理的超时设置和重试策略可能导致大量请求堆积，进一步压垮下游服务。
- 链路追踪与排障：跨多个服务的请求需要统一的 Trace ID 和 Span 上下文才能定位故障点。
- 版本兼容与契约演进：服务独立部署，接口版本不匹配可能导致序列化失败或业务逻辑错误。
常见陷阱：许多团队在微服务初期只关注功能实现，忽略通信可靠性设计。当流量增长或网络出现波动时，缺乏重试、超时、熔断和限流机制的系统会迅速崩溃。本课程的核心目标就是帮助你在 gRPC 链路中建立健壮的通信可靠性保障。
1.4 通信可靠性设计原则
面对上述挑战，微服务通信设计需要遵循以下核心原则，这些原则也是本课程后续章节（重试、超时、熔断、负载均衡）的理论基础：
- 快速失败（Fail Fast）：设置合理的超时阈值，避免请求长时间挂起占用资源。
- 优雅降级（Graceful Degradation）：当依赖服务不可用时，返回降级响应而非直接报错。
- 幂等性设计（Idempotency）：确保重试操作不会产生副作用（如重复扣款、重复下单）。
- 有限重试（Limited Retry）：重试次数和退避策略必须受控，防止重试风暴。
- 熔断隔离（Circuit Breaker）：当错误率达到阈值时，自动断开调用，给下游恢复时间。
- 可观测性（Observability）：通过分布式追踪、指标监控和日志聚合，快速定位通信故障。
课程预告：从下一章开始，我们将深入 gRPC 的通信模型，重点讲解 gRPC 内置的重试策略（Retry Policy）配置、退避算法（Exponential Backoff）、以及如何结合链路追踪实现可观测的重试行为。本章的通信概述为后续实战提供了必要的背景知识。