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

微服务不是银弹，但在合适场景下能带来巨大收益。本文分享微服务演进的实战经验。

何时考虑微服务？

单体架构的痛点

1. 代码库过大 - 新人上手需要数周
2. 部署风险高 - 小改动需要全量部署
3. 技术栈受限 - 难以引入新技术
4. 扩展不灵活 - 只能整体扩展
5. 团队效率低 - 多人协作冲突频繁

微服务适用场景

✅ 团队规模 > 10 人 ✅ 业务复杂度较高 ✅ 需要快速迭代 ✅ 不同模块负载差异大 ✅ 需要多技术栈

服务拆分策略

1. 按业务领域拆分（推荐）

用户服务      - 用户管理、认证授权
订单服务      - 订单创建、状态流转
支付服务      - 支付处理、对账
商品服务      - 商品管理、库存
通知服务      - 邮件、短信、推送

2. 按功能拆分

API Gateway
├── 读服务（高并发、缓存友好）
└── 写服务（事务一致、数据准确）

3. 按数据拆分

热数据服务 - 高频访问，内存缓存
冷数据服务 - 低频访问，成本优化

核心挑战与解决方案

1. 服务间通信

同步通信（REST/gRPC）

# gRPC 定义
service OrderService {
  rpc CreateOrder(CreateOrderRequest) returns (OrderResponse);
}

异步通信（消息队列）

# 事件驱动
order_created -> [Kafka] -> payment_service
                               inventory_service
                               notification_service

2. 数据一致性

Saga 模式

# 订单创建流程
1. 订单服务：创建订单（待支付）
2. 支付服务：扣款
3. 库存服务：扣减库存
   - 失败 -> 触发补偿：取消订单、退款

事件溯源

# 记录所有状态变更事件
OrderCreated -> OrderPaid -> OrderShipped -> OrderDelivered

# 可随时重建状态

3. 服务发现

# 使用 Consul/Eureka/Nacos
服务注册：
  POST /consul/v1/agent/register
  {"name": "order-service", "port": 8080}

服务发现：
  GET /consul/v1/health/service/order-service

4. 配置管理

# 集中配置中心
配置服务 -> Apollo/Nacos/Consul

# 各服务动态获取
config.get("database.url")
config.watch("feature.flags", callback)

基础设施要求

1. 容器化

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

2. 编排平台

# Kubernetes Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: order
        image: order-service:latest
        ports:
        - containerPort: 8080

3. API 网关

客户端 -> API Gateway -> 各微服务
         - 路由转发
         - 认证授权
         - 限流熔断
         - 日志监控

4. 可观测性

• 日志 - ELK/Loki 集中收集
• 指标 - Prometheus + Grafana
• 链路追踪 - Jaeger/Zipkin

演进路线

阶段 1：单体应用

[单体应用]

阶段 2：模块化单体

[单体应用]
├── 用户模块
├── 订单模块
└── 支付模块

阶段 3：初步拆分

[API Gateway]
├── [用户服务]
└── [单体（订单 + 支付 + 商品）]

阶段 4：完全微服务

[API Gateway]
├── [用户服务]
├── [订单服务]
├── [支付服务]
└── [商品服务]

避坑指南

❌ 过早拆分 - 初创公司先做好单体 ❌ 拆分过细 - 运维成本爆炸 ❌ 忽视数据一致性 - 业务逻辑错误 ❌ 缺少监控 - 问题难以定位 ❌ 团队结构不匹配 - Conway 定律

关键指标

指标	单体	微服务
部署频率	每周 1 次	每天多次
部署时间	30 分钟	5 分钟
故障恢复	1 小时	10 分钟
团队效率	中等	高

微服务是架构演进而非一蹴而就，根据团队和业务情况逐步推进！