1. 微服务架构概述
1.1 微服务定义
微服务架构是一种将单一应用程序划分为一组小型、独立服务的软件设计方法。每个服务运行在自己的进程中，通过轻量级通信机制（通常是 HTTP/REST 或 gRPC）相互协作。微服务的核心特征包括：
- 单一职责：每个服务只负责一个特定的业务领域或功能模块。
- 独立部署：服务可以独立开发、测试、部署和扩展，不影响其他服务。
- 技术多样性：不同服务可以使用不同的编程语言、数据库和框架。
- 去中心化治理：团队拥有服务的完整所有权，包括数据存储和 API 设计。
- 弹性与容错：单个服务的故障不会导致整个系统崩溃，通过重试、熔断等机制保障可用性。
关键指标： 微服务架构下，服务实例数量通常从几十到数千不等，服务间调用链长度可达 5-15 跳，这使得链路重试与错误处理成为系统稳定性的核心课题。
1.2 微服务与单体架构对比
理解微服务的优势与挑战，需要与传统的单体架构进行对比。下表从多个维度分析两者的差异：
| 对比维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 代码规模 | 单一代码库，通常数百万行 | 每个服务代码库独立，通常数万行 |
| 部署方式 | 全量部署，一次发布整个应用 | 独立部署，每次只更新一个或几个服务 |
| 扩展粒度 | 整体扩展，资源利用率低 | 按服务细粒度扩展，资源利用率高 |
| 故障隔离 | 故障扩散，一个模块崩溃可能导致整个系统不可用 | 故障隔离，单个服务故障不影响其他服务 |
| 通信开销 | 进程内方法调用，延迟极低（微秒级） | 网络 IPC 调用，延迟较高（毫秒级），需考虑重试与超时 |
| 数据一致性 | 本地事务 ACID，强一致性 | 分布式事务 BASE，最终一致性 |
| 团队组织 | 按技术层划分（前端、后端、DBA） | 按业务域划分（订单、支付、库存团队） |
| 测试复杂度 | 端到端测试相对简单 | 需要契约测试、服务桩、链路追踪等复杂工具 |
实践建议： 从单体向微服务迁移时，建议优先拆分变更频繁、资源消耗不均或团队边界清晰的模块。不要为了微服务而微服务，初期保持适度粒度。
1.3 微服务通信模式：同步与异步
微服务间的通信模式直接影响系统的耦合度、性能和容错能力。gRPC 作为同步通信的代表，与异步消息队列形成互补。下图展示了两种通信模式的核心差异：
在实际微服务系统中，同步与异步通信往往混合使用。下表总结了各自的最佳适用场景：
| 通信模式 | 典型协议 | 适用场景 | 重试策略 |
|---|---|---|---|
| 同步 | gRPC、HTTP/REST | 实时查询、用户交互、强一致性操作 | 有限次重试 + 指数退避 + 超时控制 |
| 异步 | Kafka、RabbitMQ、NATS | 事件通知、数据同步、批量处理、解耦 | 消息重投 + 死信队列 + 幂等消费 |
常见误区： 不要在所有场景都使用同步通信。对于跨服务的数据同步、日志收集、通知推送等非实时场景，异步消息队列能显著降低链路耦合度和重试压力。gRPC 的重试机制主要针对同步调用中的瞬时故障（如网络抖动、服务重启），而非设计用于长时间的后台重试。
1.4 微服务架构下的链路调用示例
以下是一个典型的微服务链路调用场景，展示了 gRPC 同步调用在订单处理流程中的位置：
在上图中，订单服务通过 gRPC 同步调用支付服务和库存服务，这两个调用都可能因网络抖动、服务过载或数据库锁冲突而失败。此时，gRPC 内置的重试机制 可以在客户端自动重试失败的 RPC 调用，结合指数退避策略避免对下游服务造成冲击风暴。而通知服务则通过异步消息队列解耦，即使通知发送失败，也不会阻塞主流程。
课程前置知识： 本课程后续章节将深入讲解 gRPC 的重试策略配置（RetryPolicy）、状态码分类、超时与截止时间（Deadline）、以及如何与熔断器（Circuit Breaker）配合构建高可用的微服务链路。本章的架构概述为后续内容奠定了通信模式与错误处理的基础。