企业架构演进与优化策略

// 典型问题代码
public Order createOrder(OrderRequest request) {
    // 1. 验证库存（查数据库）
    // 2. 扣减库存（更新数据库）
    // 3. 创建订单（插入数据库）
    // 4. 记录日志（插入数据库）
    // 5. 发送确认邮件（同步调用，耗时2-3秒！）
    // 用户在这里等待...
    emailService.sendConfirmEmail(user.getEmail());
    return order;
}

-- 每次页面访问都要执行的查询
SELECT * FROM products WHERE id = 123; -- 热门商品，每秒被查询100次
SELECT * FROM banners WHERE status = 'ACTIVE'; -- 首页轮播图，所有人访问都要查

// 用户投诉：“为什么我下单成功了，10分钟后才收到确认邮件？”
// 监控发现：下单接口平均响应时间1.5秒，因为：
// - 发送邮件（1秒）
// - 发送短信（0.5秒）
// - 记录用户行为日志（0.2秒）
// - 更新商品统计（0.3秒）

// 改造后：
public Order createOrder(OrderRequest request) {
    // 核心流程仅需200ms
    Order order = orderService.save(request);
    
    // 异步处理
    rabbitTemplate.convertAndSend("order.created", orderId);
    
    return order; // 立即返回
}

// 消费者异步处理
@RabbitListener(queues = "order.created")
public void handleOrderCreated(Long orderId) {
    emailService.sendConfirmEmail(orderId);  // 2-3秒也无妨
    smsService.sendSMS(orderId);
    analyticsService.track(orderId);
}

# 场景：支付团队紧急修复一个安全漏洞
# 问题：需要重新部署整个500MB的应用包
# 影响：商品团队正在进行的促销功能测试被中断
# 团队抱怨："为什么他们的改动会影响我们？"

# 解决方案：按业务域拆分
用户服务(user-service)        - 负责登录、注册、用户信息
商品服务(product-service)     - 负责商品、分类、库存
订单服务(order-service)       - 负责订单、购物车
支付服务(payment-service)     - 负责支付、退款
促销服务(promotion-service)   - 负责优惠券、秒杀活动

// 单体中所有模块必须使用相同技术栈
// 问题：AI推荐团队想用Python，但必须用Java重写
// 问题：前端团队想用GraphQL，但后端都是REST

// 微服务后：
用户服务：Java + Spring Boot    // 稳定核心业务
推荐服务：Python + FastAPI      // 适合机器学习
内容服务：Node.js + GraphQL     // 适合内容聚合

# 用户投诉："我的订单状态显示错误"
# 排查过程：
1. 查用户服务日志 - 正常
2. 查订单服务日志 - 正常  
3. 查支付服务日志 - 正常
4. 查通知服务日志 - 发现异常
# 耗时：4个工程师查了3小时

# 引入全链路追踪后：
TraceID: abc123-def456
用户服务 (20ms) → 订单服务 (150ms) → 支付服务 (300ms) → 通知服务 (ERROR: 连接超时)
# 定位时间：5分钟

# 事件：数据库慢查询导致服务雪崩
时间线：
  00:00 - 定时统计任务开始，执行复杂报表查询
  00:05 - MySQL CPU飙升到95%，连接池耗尽
  00:06 - 订单服务开始超时（监控系统告警1）
  00:07 - 用户服务响应时间从50ms增加到2s（告警2）
  00:08 - Nginx错误率超过5%（告警3）
  00:09 - 运维收到电话告警，登录系统查看
  00:15 - 发现问题SQL，终止查询，服务恢复

# 监控体系：
- 基础设施监控：CPU/内存/磁盘/网络
- 应用性能监控：响应时间/QPS/错误率
- 业务监控：订单成功率/支付成功率/库存预警
- 日志分析：ELK收集所有服务日志
- 链路追踪：追踪跨服务调用

# 场景：直播带货，流量瞬间增长10倍
# 传统云服务器：提前准备大量机器，大促后闲置
# 容器化+K8s后：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 3
  maxReplicas: 50
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
# 效果：根据CPU使用率自动扩缩容，节约30%成本

# 场景：支付服务调用第三方接口不稳定
# 问题：拖慢所有支付请求，导致订单服务线程池耗尽
# 服务网格解决方案（Istio）：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: payment-service
spec:
  hosts:
  - payment-service
  http:
  - route:
    - destination:
        host: payment-service
    retries:
      attempts: 3
      perTryTimeout: 2s
    timeout: 10s

apiVersion: networking.istio.io/v1alpha3  
kind: DestinationRule
metadata:
  name: payment-service
spec:
  host: payment-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 60s
      maxEjectionPercent: 50
# 效果：自动重试、超时控制、熔断、限流，无需改代码