微服务架构设计：从单体到分布式的演进

什么时候考虑微服务？

单体架构的痛点

• 代码库庞大，难以理解
• 部署周期长，风险高
• 技术栈固化，难以升级
• 团队协作效率下降
• 扩展性差 (只能整体扩展)

微服务的适用场景

✅ 团队规模较大 (10+ 人) ✅ 业务复杂度高，模块边界清晰 ✅ 需要快速迭代和独立部署 ✅ 不同模块有不同技术需求 ✅ 需要弹性伸缩

❌ 初创团队，业务未验证 ❌ 简单应用，复杂度低 ❌ 缺乏 DevOps 能力

服务拆分原则

1. 单一职责原则

每个服务只负责一个业务领域：

用户服务 (User Service)
  - 用户注册/登录
  - 用户信息管理
  - 权限认证

订单服务 (Order Service)
  - 订单创建
  - 订单状态管理
  - 订单查询

支付服务 (Payment Service)
  - 支付处理
  - 退款管理
  - 对账

2. 高内聚低耦合

• 相关功能放在同一服务
• 服务间通过 API 通信
• 避免共享数据库

3. 数据一致性

每个服务拥有自己的数据库：

✅ 用户服务 → users_db
✅ 订单服务 → orders_db
✅ 支付服务 → payments_db

❌ 所有服务共享一个数据库

服务通信

同步通信 (HTTP/RPC)

// REST API
GET /api/users/123

// gRPC (性能更好)
service UserService {
  rpc GetUser(GetUserRequest) returns (User);
}

适用场景: 实时性要求高，需要立即响应

异步通信 (消息队列)

订单服务 → Kafka → 库存服务
                  → 通知服务
                  → 分析服务

适用场景: 解耦服务，削峰填谷，最终一致性

关键挑战与解决方案

1. 服务发现

问题: 服务如何找到彼此？

方案:

• Consul
• etcd
• Kubernetes Service
• Eureka

2. 负载均衡

方案:

• 客户端负载均衡 (Ribbon)
• 服务端负载均衡 (Nginx, ALB)

3. 容错与熔断

// 熔断器模式
if (failureCount > threshold) {
  // 快速失败，不调用下游
  return fallback();
}

工具: Hystrix, Resilience4j, Istio

4. 分布式追踪

工具:

• Jaeger
• Zipkin
• SkyWalking

作用: 追踪请求在多个服务间的流转

5. 配置管理

工具:

• Apollo
• Nacos
• Spring Cloud Config

部署与运维

容器化

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

编排工具

• Kubernetes: 行业标准
• Docker Swarm: 简单易用
• Nomad: 灵活轻量

CI/CD 流水线

代码提交 → 构建 → 测试 → 打包镜像 → 部署 → 验证

监控告警

三大支柱

1. Metrics: Prometheus + Grafana
2. Logging: ELK / Loki
3. Tracing: Jaeger / Zipkin

关键指标

• 请求量 (QPS)
• 响应时间 (P50/P95/P99)
• 错误率
• 饱和度 (CPU/内存)

总结

微服务不是银弹。评估团队能力、业务需求，渐进式演进。先做好单体，再考虑拆分。