微服务架构设计：拆分、通信与治理

什么是微服务？

微服务是将单体应用拆分为小型、独立部署的服务：

• 每个服务负责单一业务功能
• 服务间通过 API 通信
• 独立开发、部署、扩展

服务拆分原则

单一职责

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

用户服务：注册、登录、个人信息
订单服务：下单、支付、退款
商品服务：商品管理、库存、价格

领域驱动设计 (DDD)

// 按业务领域划分
/ecommerce
  /user
  /order
  /product
  /payment

数据库分离

❌ 所有服务共享一个数据库
✅ 每个服务独立数据库

服务通信

同步通信 (HTTP/RPC)

// HTTP REST
const user = await fetch("http://user-service/users/123");

// gRPC (更高效)
const user = await userService.getUser({ id: 123 });

优点：简单、实时 缺点：耦合度高、级联故障

异步通信 (消息队列)

// 发布/订阅模式
await kafka.produce("order-created", { orderId: 123 });

// 订阅者处理
kafka.consume("order-created", async (event) => {
  await sendNotification(event.orderId);
});

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

服务治理

服务发现

# Consul 配置
services:
  - name: user-service
    port: 8080
    check:
      http: http://localhost:8080/health
      interval: 10s

负载均衡

• 客户端负载均衡：Ribbon
• 服务端负载均衡：Nginx、HAProxy

熔断降级

import { CircuitBreaker } from "opossum";

const breaker = new CircuitBreaker(callExternalService, {
  timeout: 3000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000
});

breaker.fire().then(result => {
  // 处理结果
}).catch(err => {
  // 熔断后的降级逻辑
});

链路追踪

请求 → API Gateway → User Service → Order Service
       ↓              ↓               ↓
    Jaeger/Zipkin 收集追踪信息

配置管理

# 集中配置中心
config-server:
  user-service:
    database: mysql://user-db
    cache: redis://cache
  order-service:
    database: mysql://order-db

挑战与解决

挑战	解决方案
数据一致性	Saga 模式、事件溯源
分布式事务	TCC、最终一致性
服务监控	Prometheus + Grafana
日志聚合	ELK Stack

何时使用微服务？

适合：

• 团队规模大（>10 人）
• 业务复杂，需要独立扩展
• 技术栈多样化需求

不适合：

• 初创项目，快速验证
• 小团队（<5 人）
• 简单业务场景

结语

微服务不是银弹，带来灵活性的同时也增加复杂性。根据团队和业务情况慎重选择。