微服务

📅 2026-04-02 ✏️ 2026-04-02 CS

No related notes

1 · 微服务

S 单体架构是构建应用的传统方式：所有功能打包在一个进程里，开发、部署、调试简单直接。 C 随着业务增长和团队扩大，单体变成”大泥球”——构建慢、部署风险高、团队互相阻塞、局部扩展不可能。 Q 如何在保持交付速度的同时，让系统具备独立演进和弹性扩展的能力？ A 按业务能力拆分为一组小型、自治的服务（微服务），每个服务独立开发、部署、扩展，通过轻量级通信协作。

怎么拆？之间怎么通信？各自的数据如何管理？

1.1 · 核心特征

特征	说明
单一职责	一个服务只做一件事，围绕一个 bounded context 建模
自治	独立代码库、独立部署、独立数据存储
去中心化治理	团队可自主选择语言、框架、存储
为失败设计	假设网络不可靠，做好熔断、重试、降级
可独立替换	服务可以被重写而不影响其他服务

1.2 · 拆分策略

按业务能力（Business Capability）：订单、支付、库存各自成服务。最常用，和组织架构对齐（Conway’s Law）。
按子域（Subdomain）：用 DDD 识别 bounded context，核心域、支撑域、通用域分别建服务。
Strangler Fig 模式：从单体边缘逐步抽取服务，新功能用新服务，旧功能逐步迁移。

⚠️ 拆分粒度没有标准答案。过细导致”分布式单体”，过粗又退化为单体。经验法则：一个服务能被一个小团队（2-pizza team）拥有和理解。

1.3 · 通信模式

1.3.1 · 同步

方式	特点
REST / HTTP	简单通用，适合 CRUD 场景
gRPC	强类型 + 高性能，适合内部服务间调用

1.3.2 · 异步

方式	特点
消息队列（Kafka / RabbitMQ）	解耦生产者和消费者，削峰填谷
事件驱动（Event-Driven）	服务发布领域事件，其他服务订阅响应

优先选异步：降低耦合、提高弹性；只在需要即时响应时才用同步。

1.4 · 数据管理

Database per Service：每个服务拥有自己的数据库，杜绝直接访问他人数据。
跨服务查询：用 API Composition 或 CQRS（Command Query Responsibility Segregation）。
分布式事务：
- 避免两阶段提交（2PC）——性能差、可用性低。
- 用 Saga 模式：把事务拆成一系列本地事务 + 补偿操作。
  - 编排式（Choreography）：服务间通过事件协调。
  - 指挥式（Orchestration）：由一个协调器统一指挥。

1.5 · 关键挑战

1.5.1 · 可观测性

LTM: log trace metric

分布式追踪（OpenTelemetry / Jaeger）：跟踪请求在多个服务间的链路。
集中日志（ELK / Loki）：统一收集、关联日志。
指标监控（Prometheus + Grafana）：延迟、错误率、吞吐量。

1.5.2 · 服务治理

服务发现：Consul / etcd / K8s DNS。
负载均衡：客户端（gRPC）或服务端（Nginx / Envoy）。
API Gateway：统一入口，处理认证、限流、路由。
Service Mesh（Istio / Linkerd）：将通信治理下沉到 sidecar，应用代码无感知。

1.5.3 · 弹性模式

熔断器（Circuit Breaker）：下游故障时快速失败，防止级联崩溃。
重试 + 退避：指数退避 + 抖动（jitter），避免重试风暴。
限流（Rate Limiting）：保护服务不被突发流量压垮。
舱壁（Bulkhead）：隔离资源池，一个调用方的问题不影响其他调用方。

1.6 · 何时不该用微服务

团队 < 10 人，单体足够。
领域边界不清晰，过早拆分只会反复重构。
没有自动化基础设施（CI/CD、容器编排、监控），运维成本会吞噬开发效率。
低延迟要求极高的场景（如高频交易），进程间通信开销不可接受。

微服务不是目标，独立交付能力才是目标。如果模块化单体（Modular Monolith）能满足需求，就不需要微服务。