微服务架构完全指南

微服务是现代大型系统的标准架构。本文详解从单体到微服务的完整演进路径。

架构演进历程

单体架构

┌─────────────────────────┐
│      单体应用            │
│  ┌─────┬─────┬─────┐   │
│  │用户 │订单 │商品 │   │
│  │模块 │模块 │模块 │   │
│  └─────┴─────┴─────┘   │
│       共享数据库         │
└─────────────────────────┘

优点：

• 开发简单，本地调试方便
• 部署简单，一个包搞定
• 事务容易保证

缺点：

• 代码耦合严重
• 扩展性差（只能整体扩展）
• 技术栈绑定
• 单点故障风险

微服务架构

┌─────────┐  ┌─────────┐  ┌─────────┐
│ 用户服务 │  │ 订单服务 │  │ 商品服务 │
│  + DB   │  │  + DB   │  │  + DB   │
└────┬────┘  └────┬────┘  └────┬────┘
     │            │            │
     └────────────┼────────────┘
                  │
           ┌──────┴──────┐
           │   API 网关    │
           └─────────────┘

优点：

• 服务独立，解耦清晰
• 可独立扩展
• 技术栈灵活
• 故障隔离

缺点：

• 复杂度高
• 分布式事务难
• 运维成本高

服务拆分原则

1. 单一职责

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

✅ 用户服务：用户注册、登录、信息管理
✅ 订单服务：下单、支付、退款
✅ 商品服务：商品管理、库存、价格
❌ 电商服务：什么都做

2. 高内聚低耦合

✅ 订单服务内部处理订单逻辑
✅ 通过 API 调用其他服务
❌ 直接访问其他服务的数据库

3. 数据私有化

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

# ✅ 正确：通过 API 获取数据
class OrderService:
    def create_order(self, user_id):
        user = user_service.get_user(user_id)  # API 调用
        
# ❌ 错误：直接查库
class OrderService:
    def create_order(self, user_id):
        user = db.query("SELECT * FROM users WHERE id = ?", user_id)

核心组件

1. 服务注册与发现

# Consul 配置
services:
  - name: user-service
    port: 8080
    health: /health
    
  - name: order-service
    port: 8081
    health: /health

工作流程：

1. 服务启动时注册到注册中心
2. 服务调用时从注册中心获取实例
3. 健康检查，自动剔除故障实例

2. API 网关

# Kong 配置
routes:
  - name: user-route
    paths: ["/api/users"]
    service: user-service
    
  - name: order-route
    paths: ["/api/orders"]
    service: order-service

网关职责：

• 路由转发
• 认证授权
• 限流熔断
• 日志监控

3. 配置中心

# Apollo 配置
application: order-service
namespace: application

config:
  database.url: jdbc:mysql://db:3306/orders
  redis.host: redis:6379
  log.level: INFO

4. 链路追踪

# Jaeger 集成
from jaeger_client import Config

config = Config(
    config={"sampler": {"type": "const", "param": 1}},
    service_name="order-service"
)
tracer = config.initialize_tracer()

with tracer.start_span("create_order") as span:
    # 业务逻辑
    pass

服务通信

同步调用（HTTP/RPC）

# HTTP (REST)
import requests

response = requests.get("http://user-service/users/123")
user = response.json()

# RPC (gRPC)
user = user_stub.GetUser(UserRequest(id=123))

优点： 简单直观 缺点： 耦合度高，级联故障

异步通信（消息队列）

# Kafka 生产者
producer.send("order-created", {
    "order_id": 123,
    "user_id": 456
})

# Kafka 消费者
@consumer.group("order-processor")
def process_order(message):
    # 处理订单
    pass

优点： 解耦，削峰填谷 缺点： 复杂度高，最终一致性

分布式事务

1. Saga 模式

# 订单创建流程
def create_order():
    try:
        # 步骤 1：扣减库存
        inventory_service.deduct(stock_id, qty)
        
        # 步骤 2：创建订单
        order = order_service.create(order_data)
        
        # 步骤 3：扣减余额
        account_service.deduct(user_id, amount)
        
    except Exception as e:
        # 补偿操作
        inventory_service.compensate(stock_id, qty)
        order_service.cancel(order.id)

2. 本地消息表

def create_order():
    # 1. 本地事务：创建订单 + 写入消息表
    db.transaction()
    order = create_order_record()
    save_message("order-created", order.id)
    
    # 2. 异步：发送消息
    async_send_message()

容错机制

1. 超时控制

import requests
from requests.adapters import HTTPAdapter

session = requests.Session()
session.mount("http://", HTTPAdapter(
    max_retries=3,
    timeout=5  # 5 秒超时
))

2. 熔断器

from pybreaker import CircuitBreaker

@circuit breaker(fail_max=5, reset_timeout=30)
def call_user_service():
    return requests.get("http://user-service/users/123")

3. 限流

from flask_limiter import Limiter

limiter = Limiter(key_func=get_remote_address)

@app.route("/api/orders")
@limiter.limit("100/minute")
def create_order():
    pass

部署架构

# Kubernetes 部署
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: order
        image: order-service:1.0
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080

监控告警

• 指标监控： Prometheus + Grafana
• 日志收集： ELK Stack
• 链路追踪： Jaeger/Zipkin
• 告警通知： PagerDuty/钉钉

微服务不是银弹，适合业务复杂、团队规模大的场景。小团队建议从单体开始，逐步演进！