// 所有东西搅在一起——就像中世纪的城市
class OrderService {
    void createOrder() {
        // 订单逻辑
        // 库存扣减逻辑
        // 支付逻辑
        // 物流逻辑
        // 通知逻辑
        // 用户积分逻辑
        // 优惠券核销逻辑
    }
}

// 订单上下文——只管订单
class OrderService {
    void createOrder(OrderRequest req) {
        Order order = orderRepo.save(req.toOrder());
        eventBus.publish(new OrderCreatedEvent(order.getId()));
    }
}

// 库存上下文——只管库存
class InventoryService {
    @EventHandler
    void on(OrderCreatedEvent e) {
        inventoryRepo.deduct(e.getOrderId(), e.getItems());
    }
}

// 支付上下文——只管支付
class PaymentService {
    @EventHandler
    void on(OrderCreatedEvent e) {
        paymentGateway.charge(e.getOrderId(), e.getAmount());
    }
}

过度拆分的微服务：
用户姓名查询 → 调用用户服务
用户地址查询 → 调用地址服务  
用户偏好查询 → 调用偏好服务
用户头像查询 → 调用头像服务

一个简单的用户资料页要调 5 个服务
延迟 = max(5 个服务) + 序列化 × 5 + 网络开销 × 5

所有服务 → 一个大数据库

  用户服务 ─┐
  订单服务 ─┤
  支付服务 ─┼──→ [超级大数据库] ← 瓶颈！
  物流服务 ─┤
  报表服务 ─┘

用户服务 → [用户库]      订单服务 → [订单库]
支付服务 → [支付库]      物流服务 → [物流库]

服务之间通过事件/API通信，而非共享数据库

# 两个同进程内的模块，却用 Kafka 通信
Module A → Kafka → Module B

# 等同于：出门倒垃圾，先上高速公路，再下来
# 开销：序列化 + 网络传输 + Broker 中转 + 反序列化
# 正确做法：直接方法调用

# 两个独立部署的服务，通过共享数据库表"通信"
Service A 写入 shared_table，Service B 轮询读取

# 等同于：用乡村小路跑集装箱卡车
# 问题：耦合、性能差、无法独立部署

# 城市限号 → 限流
限号: 每天只允许尾号 1/3/5/9 的车上路
限流: 每秒只允许 1000 个请求通过

# 交通管制 → 熔断
前方事故 → 封路 → 车辆绕行
下游服务故障 → 熔断 → 请求走降级路径

// Resilience4j 熔断器——就像交通管制
CircuitBreaker breaker = CircuitBreaker.ofDefaults("paymentService");
Supplier<String> supplier = CircuitBreaker.decorateSupplier(
    breaker, 
    () -> paymentService.charge(request)  // 正常路线
);
String result = Try.ofSupplier(supplier)
    .recover(throwable -> fallbackCharge(request))  // 绕行路线
    .get();

反模式：
1. 先写业务代码
2. 上线后出 Bug
3. "加个日志吧"
4. 日志打了，发现信息不够
5. 再加指标
6. 指标加了，发现没有告警
7. 告警配了，发现找不到根因（缺链路追踪）
8. 补链路追踪——但要改所有服务

→ 每一步都是补救，总成本远大于一开始就搭建好

精益做法：
1. 先搭建可观测性基座（日志 + 指标 + 链路追踪）
2. CI/CD 流水线就位
3. 安全基线配置好
4. 再开始写业务代码

→ 业务代码天然就在基础设施的"保护"下运行
→ 出问题时，三分钟定位而非三小时猜测

# 基础设施先行的实践：新服务脚手架
service-template/
├── Dockerfile              # 容器化
├── .github/workflows/      # CI/CD
├── health/                 # 健康检查
│   ├── readiness.py
│   └── liveness.py
├── observability/          # 可观测性
│   ├── logging.py          # 结构化日志
│   ├── metrics.py          # Prometheus 指标
│   └── tracing.py          # OpenTelemetry 链路追踪
├── security/               # 安全基线
│   ├── auth.py             # 认证中间件
│   └── rate_limit.py       # 限流
└── src/                    # 业务代码——最后才写
    └── ...

"现有系统太烂了，我们用最新技术栈重写！"

旧系统：能跑，虽然丑
新系统：设计完美，但——
  - 花了 18 个月
  - 遗漏了旧系统的 100 个边界 case
  - 上线后用户投诉：功能还不如旧的
  - 最终两套系统并行运行（更糟了）

策略：绞杀者模式（Strangler Fig Pattern）

旧系统继续运行，新系统逐步替代：
1. 在旧系统前加一层路由（Facade）
2. 新功能用新架构写，路由指向新系统
3. 旧功能逐个迁移到新系统
4. 每迁移一个，旧系统就小一分
5. 最终旧系统被"绞杀"——自然退役

  请求 → [路由层] → 新服务（优先）
                ↘ 旧系统（降级）

迁移进度：
Week 1:  5% 请求走新系统
Week 4:  30% 请求走新系统
Week 8:  70% 请求走新系统
Week 12: 100% 请求走新系统 → 旧系统下线

# 演进式迁移：特性开关控制
def process_order(order):
    if feature_flags.is_enabled("new_order_service"):
        try:
            return new_order_service.process(order)
        except Exception as e:
            log.error(f"New service failed: {e}")
            return legacy_order_service.process(order)  # 降级
    else:
        return legacy_order_service.process(order)

# 好的 API 设计——像好广场
/api/v2/orders:
  get:
    summary: 查询订单
    parameters:
      - status: 按状态筛选
      - page: 分页
    responses:
      200:
        content:
          application/json:  # 标准 MIME
        links:
          payment: /api/v2/payments/{orderId}  # 引导到关联资源
          tracking: /api/v2/logistics/{shipmentId}
    # HATEOAS：像广场上的路标，告诉你还能去哪

// 差的 API——像摩西的高速公路
// 返回内部数据库字段，消费者被锁死在实现上
@GetMapping("/internal/orders")
Map<String, Object> getOrder(@RequestParam String ord_id) {
    // 直接返回数据库行——字段名、类型、结构全暴露
    return jdbcTemplate.queryForMap("SELECT * FROM t_ord WHERE id = ?", ord_id);
}

非韧性架构：
  单点故障 → 雪崩 → 全站挂

韧性架构：
  局部故障 → 降级 → 核心功能仍可用

def get_product_detail(product_id):
    """韧性设计：每个依赖都有降级方案"""

    # 核心数据——必须成功
    product = product_repo.get(product_id)
    if not product:
        raise NotFoundError(f"Product {product_id} not found")

    # 非核心：评论——挂了也能看商品
    reviews = safe_call(
        lambda: review_service.get_reviews(product_id),
        fallback=[]  # 降级：返回空评论
    )

    # 非核心：推荐——挂了也不影响
    recommendations = safe_call(
        lambda: recommend_service.get_similar(product_id),
        fallback=[]  # 降级：返回空推荐
    )

    # 非核心：库存——挂了显示"查询中"
    stock = safe_call(
        lambda: inventory_service.get_stock(product_id),
        fallback={"status": "unknown", "text": "库存查询中"}
    )

    return {
        "product": product,       # 核心
        "reviews": reviews,       # 非核心，降级
        "recommendations": recommendations,  # 非核心，降级
        "stock": stock            # 非核心，降级
    }

旧系统中一个看起来"多余"的判断：

if order.amount > 10000 and user.level == "silver" and order.type != "bulk":
    order.add_flag("MANUAL_REVIEW")

新系统重写时，有人看了这行觉得"没意义"就删了。
结果：上线后，大额银牌用户的异常订单没人审核，造成损失。

→ 那行代码是"城市记忆"：它记录了一次事故的教训。