1.1 微服务架构概述
1.1.1 微服务定义
微服务架构是一种将单一应用程序划分为一组小型、独立部署的服务的软件设计方法。每个微服务围绕业务能力构建，拥有自己的数据存储、独立的部署流水线，并通过轻量级通信机制（通常是 HTTP/REST 或 gRPC）相互协作。
微服务的核心特征包括：
- 单一职责：每个服务只负责一个特定的业务领域（Bounded Context）。
- 独立部署：服务可以独立于其他服务进行构建、测试、部署和扩展。
- 去中心化治理：允许不同服务使用不同的技术栈、编程语言和数据存储。
- 弹性与容错：单个服务的故障不会导致整个系统崩溃，通过熔断、重试、超时等机制实现隔离。
- 自动化运维：依赖 CI/CD、容器化（Docker）、编排（Kubernetes）和可观测性（日志、指标、链路追踪）基础设施。
关键认知：微服务不是银弹。它通过拆分复杂度换取了运维和通信的复杂度。在引入微服务之前，必须建立好服务发现、配置中心、链路追踪和容器编排等基础设施。
1.1.2 微服务与单体架构对比
单体架构将所有功能模块打包在同一个进程中运行，而微服务架构将功能分散到多个独立进程中。下表从多个维度对比两种架构的差异：
| 对比维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 代码库规模 | 单一代码仓库，代码量大，编译慢 | 多个小型代码仓库，每个服务独立管理 |
| 部署方式 | 全量部署，一次部署影响整个系统 | 独立部署，仅更新变更的服务 |
| 扩展粒度 | 只能整体水平扩展，资源浪费 | 按服务维度精确扩展，资源利用率高 |
| 技术栈 | 单一技术栈，语言和框架绑定 | 多语言、多框架，按需选择 |
| 故障隔离 | 一个模块的故障（如内存泄漏）可能导致整个进程崩溃 | 故障被限制在单个服务内，通过熔断和降级保护上游 |
| 通信开销 | 进程内函数调用，延迟极低（纳秒级） | 进程间网络调用，延迟较高（毫秒级），需考虑序列化/反序列化 |
| 调试与测试 | 端到端测试简单，但回归测试范围大 | 服务级单元测试容易，但端到端测试需要模拟多个服务 |
| 运维复杂度 | 低，只需管理一个应用 | 高，需要服务发现、配置中心、日志聚合、链路追踪等基础设施 |
架构迁移建议：从单体向微服务演进时，推荐采用“绞杀者模式”（Strangler Fig Pattern），逐步将单体中的功能模块剥离为独立微服务，而不是一次性重写整个系统。
1.1.3 微服务通信模式
微服务之间的通信模式直接影响系统的耦合度、延迟和可靠性。根据通信的同步/异步特性，主要分为以下两类：
同步通信模式
- HTTP/REST：基于 HTTP 协议，使用 JSON/XML 序列化。优点是简单、通用、防火墙友好；缺点是文本协议效率低，不适合高吞吐场景。
- gRPC：基于 HTTP/2 协议，使用 Protocol Buffers 序列化。优点是高性能、强类型、支持双向流和流式控制；缺点是客户端和服务端需共享 proto 文件，调试工具不如 REST 丰富。
- GraphQL：允许客户端精确指定所需字段，减少数据过度获取。适用于 BFF（Backend For Frontend）层，但查询复杂度控制较难。
异步通信模式
- 消息队列（Message Queue）：如 Kafka、RabbitMQ、Pulsar。生产者将消息发送到队列，消费者异步拉取。优点是解耦、削峰填谷、提高系统弹性；缺点是引入消息中间件，增加运维成本和最终一致性处理复杂度。
- 事件驱动（Event-Driven）：服务通过发布/订阅事件进行通信。事件总线（如 Apache Kafka、NATS）负责路由事件。适用于跨服务状态同步和 CQRS 模式。
- 响应式流（Reactive Streams）：基于背压（Backpressure）机制的异步数据流，如 RSocket。适用于需要精细控制流量和延迟的场景。
下表总结了同步与异步通信模式的关键差异：
| 特性 | 同步通信（gRPC/REST） | 异步通信（消息队列） |
|---|---|---|
| 耦合度 | 时间耦合：调用方必须等待响应 | 时间解耦：发送方无需等待消费者处理 |
| 延迟 | 低延迟（毫秒级），但受网络抖动影响 | 较高延迟（毫秒到秒级），取决于队列积压 |
| 可靠性 | 依赖重试和超时机制，需处理幂等性 | 消息持久化，支持至少一次/精确一次语义 |
| 流量控制 | 通过限流和熔断保护下游 | 通过队列长度和消费者速率自然削峰 |
| 典型场景 | 实时查询、用户交互、支付确认 | 日志收集、订单状态同步、通知推送 |
常见误区：不要将所有服务间通信都改为异步。对于需要强一致性和实时响应的场景（如扣减库存、转账），同步通信配合幂等重试是更合适的选择。异步通信适用于最终一致性场景。
下图展示了微服务架构中常见的通信拓扑，包括同步调用链和异步事件流：
在本课程后续章节中，我们将重点聚焦于 gRPC 同步通信场景下的超时与重试配置。gRPC 作为高性能 RPC 框架，在微服务链路中承担着核心的同步调用职责，其超时策略和重试机制直接决定了系统的端到端延迟和可用性。
课程前置知识：理解微服务通信模式是掌握 gRPC 超时重试的基础。同步调用中的超时设置、重试策略、幂等性设计，以及异步通信中的消息可靠投递，都是后续故障排查章节的核心内容。