微服务
微服务架构的定义、核心特征、常见模式与挑战
#tech / dev / backend
#type / concept
#status / growing
微服务 Microservices
一句话定义
微服务是一种架构风格，将应用拆分为一组小型、独立部署的服务，每个服务围绕一个业务能力构建，通过轻量级 API 通信。
核心机制 / 工作原理
核心特征
- 单一职责 — 每个服务只负责一个业务能力（如订单服务、支付服务、库存服务）
- 独立部署 — 每个服务可以独立编译、测试、部署，不影响其他服务
- 去中心化数据管理 — 每个服务拥有自己的数据库，不共享数据存储
- API 通信 — 服务间通过 HTTP/gRPC/消息队列通信，而非直接方法调用
- 技术异构 — 不同服务可以使用不同的语言、框架、数据库
微服务 vs 单体
| 维度 | 单体 | 微服务 |
|---|---|---|
| 部署 | 整体部署 | 独立部署 |
| 扩展 | 整体扩展 | 按需扩展单个服务 |
| 技术栈 | 统一 | 可异构 |
| 数据库 | 共享 | 每个服务独立 |
| 复杂度 | 代码层面 | 架构/运维层面 |
| 团队 | 大团队协调 | 小团队自治 |
常见模式
- API Gateway — 统一入口，路由请求到对应的微服务，处理认证、限流、负载均衡
- 服务发现 — 服务实例动态注册/发现（如 Consul, Eureka, Nacos）
- 断路器 (Circuit Breaker) — 当下游服务故障时快速失败，防止级联崩溃（如 Hystrix, Resilience4j）
- 事件驱动 — 通过消息队列（Kafka, RabbitMQ）实现异步通信和最终一致性
- Saga 模式 — 管理跨服务的分布式事务，通过编排或协调一系列本地事务
- Sidecar 模式 — 将通用功能（日志、监控、认证）抽到独立代理进程中
最小例子
客户端
|
v
[API Gateway :8080]
| | |
v v v
[订单服务] [用户服务] [库存服务]
| | |
v v v
[订单DB] [用户DB] [库存DB]订单服务创建订单时：
- 通过 API Gateway 接收请求
- 调用库存服务扣减库存（同步 HTTP）
- 发送”订单已创建”事件到消息队列（异步）
- 用户服务订阅该事件，发送通知
边界与常见误解
- “微服务总是更好” — 错。微服务引入分布式系统的复杂性。对于小团队/早期项目，单体往往是更务实的选择。
- “每个服务很小就是微服务” — 关键不是代码量小，而是边界清晰、独立部署、团队自治。
- “微服务 = 容器化” — 容器（Docker）和编排（K8s）是实现微服务的常见工具，但不是定义的一部分。
- 分布式事务难题 — 跨服务的强一致性很难实现，通常采用最终一致性 + Saga 模式。
- 可观测性挑战 — 需要分布式追踪（Jaeger, Zipkin）、集中日志（ELK）、服务网格（Istio）来排查问题。
- 数据一致性 — 每个服务独立数据库意味着不能用传统 ACID 事务，需要事件溯源或补偿机制。