微服务架构设计实战

一、架构演进

1.1 演进路线

单体架构 → 垂直拆分 → SOA → 微服务 → 云原生

阶段	特点	适用场景
单体架构	所有功能在一个应用	初创期，快速迭代
垂直拆分	按业务拆分为多个应用	业务增长，团队扩张
SOA	服务总线 (ESB) 集成	企业级系统集成
微服务	轻量级通信，去中心化	高并发，快速交付
云原生	容器化，服务网格	弹性伸缩，DevOps

1.2 微服务特征

mindmap
  root((微服务特征))
    单一职责
      每个服务只做好一件事
    独立部署
      服务可独立发布上线
    去中心化
      技术栈数据库独立
    轻量通信
      RESTful API/RPC/消息

二、服务拆分

2.1 拆分原则

mindmap
  root((DDD 领域驱动设计))
    战略设计
      限界上下文 Bounded Context
      子域划分
        核心域
        支撑域
        通用域
      上下文映射 Context Map
    战术设计
      实体 Entity
      值对象 Value Object
      聚合根 Aggregate Root
      领域服务 Domain Service

2.2 拆分策略

策略	说明	示例
按业务领域	根据业务功能划分	用户服务、订单服务、支付服务
按数据读写	读写分离、CQRS	订单查询服务、订单写入服务
按并发量	高并发服务独立	秒杀服务独立部署
按变更频率	频繁变更的服务独立	营销活动服务

2.3 服务依赖

graph TD
    A[API Gateway] --> B[用户服务]
    A --> C[订单服务]
    A --> D[商品服务]
    C --> B
    C --> D
    C --> E[支付服务]
    E --> F[消息服务]

三、服务治理

3.1 服务注册与发现

graph LR
    Provider[服务提供者] --> Nacos[Nacos 注册中心]
    Consumer[服务消费者] --> Nacos

# Nacos 配置
spring:
  cloud:
    nacos:
      discovery:
        server-addr: nacos:8848
        namespace: dev
        group: DEFAULT_GROUP

3.2 负载均衡

// Ribbon 配置
@Configuration
public class RibbonConfig {
    @Bean
    public IRule loadBalanceRule() {
        return new WeightedResponseTimeRule(); // 响应时间加权
    }
}

策略	说明
轮询	依次分配请求
随机	随机选择服务
加权响应时间	响应越快权重越高
最少连接数	优先选择连接数少的

3.3 熔断降级

@SentinelResource(
    value = "getUser",
    blockHandler = "handleBlock",      // 限流处理
    fallback = "handleFallback",        // 降级处理
    exceptionsToIgnore = {NullPointerException.class}
)
public User getUser(Long id) {
    return userClient.getUser(id);
}

3.4 配置中心

graph LR
    Config[配置中心 Apollo/Nacos] -->|推送 | App[服务实例]
    App --> Cache[本地缓存]
    Cache --> Refresh[动态刷新]

四、分布式事务

4.1 CAP 理论

graph TB
    CAP[CAP 理论]
    CAP --> C[一致性<br/>Consistency]
    CAP --> A[可用性<br/>Availability]
    CAP --> P[分区容错性<br/>Partition tolerance]
    CAP -.最多满足两项.-> CAP

4.2 解决方案

方案	一致性	性能	适用场景
2PC	强一致	低	金融交易
TCC	最终一致	中	订单支付
本地消息表	最终一致	高	异步场景
Saga	最终一致	高	长流程
Seata	可配置	中	通用场景

4.3 Seata 实战

@GlobalTransactional
public void createOrder(Order order) {
    // 1. 扣减库存
    inventoryClient.deduct(order.getSkuId(), order.getCount());
    
    // 2. 扣减余额
    accountClient.deduct(order.getUserId(), order.getAmount());
    
    // 3. 创建订单
    orderMapper.insert(order);
}

五、API 网关

5.1 核心功能

graph TB
    Req[请求] --> GW[网关]
    GW --> Auth[认证鉴权]
    GW --> Limit[限流熔断]
    GW --> Log[日志监控]
    GW --> Route[路由转发]
    GW --> Svc[服务]

六、可观测性

6.1 链路追踪

sequenceDiagram
    participant U as 用户请求
    participant G as Gateway
    participant O as Order
    participant US as User
    participant DB as DB
    
    U->>G: TraceID
    G->>O: Span1
    O->>US: Span2
    US->>DB: Span3

请求 → 网关 → 服务 ↓ 认证鉴权限流熔断日志监控路由转发


### 5.2 Spring Cloud Gateway

```yaml
spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: lb://user-service
          predicates:
            - Path=/api/users/**
          filters:
            - StripPrefix=1
            - RequestRateLimiter=10, 20  # 令牌桶限流

六、可观测性

6.1 链路追踪

用户请求 → Gateway → Order → User → DB
   ↓        ↓         ↓       ↓
 TraceID  Span1     Span2   Span3

<!-- SkyWalking 集成 -->
<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-agent</artifactId>
</dependency>

6.2 日志聚合

graph LR
    App[App] --> FB[Filebeat]
    FB --> K[Kafka]
    K --> LS[Logstash]
    LS --> ES[Elasticsearch]
    ES --> KB[Kibana]

6.3 监控告警

graph TB
    P[Prometheus<br/>指标采集] --> G[Grafana<br/>可视化]
    G --> A[AlertManager<br/>告警通知]

七、最佳实践

7.1 服务设计

接口设计：RESTful 规范，版本控制
幂等性：POST/PUT 接口支持重试
超时控制：设置合理的超时时间
重试机制：指数退避重试

7.2 数据库设计

数据库隔离：每个服务独立数据库
分库分表：数据量大时提前规划
读写分离：查询多的场景

7.3 安全设计

认证：JWT / OAuth2
鉴权：RBAC 权限模型
加密：敏感数据加密存储
审计：操作日志记录

总结

微服务架构设计要点：

合理拆分：DDD 领域驱动，单一职责
服务治理：注册发现、负载均衡、熔断降级
数据一致：根据场景选择事务方案
可观测性：链路追踪、日志聚合、监控告警
持续演进：架构不是一蹴而就，需要持续优化

微服务不是银弹，适合的才是最好的