云设计模式

这一课你将能做到

1. 用 Bulkhead（舱壁）为本站读路径与写路径配置资源隔离，说清它如何限制故障爆炸半径
2. 设计 Valet Key（代客密钥）流程，让用户头像/题解附件绕过应用服务器直传对象存储
3. 用 Claim Check（引用票据）解决 Kafka 大消息问题，用 Anti-Corruption Layer 隔离外部格式

为什么要学

前几课解决「怎么扛量」，这课解决「怎么不因一处损坏而全站陪葬」。云设计模式是一批被反复验证的架构套路，名字来自 Microsoft Azure 架构模式库——不管上不上云，这些模式都适用。

面试里它们是加分项：「你了解哪些架构模式？」「大文件上传怎么设计？」「一个慢依赖怎么防止拖垮整个服务？」——能按名字、问题、解法三段式讲清楚，说明你有体系而非碎片经验。

人话：Bulkhead 是船的水密舱——一个舱进水，船不沉；Valet Key 是代客泊车的钥匙——只给停车（上传）权限，不给后备箱（删除）；Claim Check 是寄存行李——排队票上写编号，行李放仓库，别扛着大箱子排队；Anti-Corruption Layer 是翻译官——外部格式再乱，翻译成本公司语言后才进门。

先建立图像

本站的四个问题与对应模式：

模式	解决的问题	本站落地
Bulkhead	写判题结果慢，占满连接池，读也死	读/写独立连接池 + 判题机独立部署单元
Valet Key	题解 PDF 50MB，经 Java 中转费带宽	签发限时预签名 URL，浏览器直传 MinIO
Claim Check	提交代码 200KB 塞进 Kafka 消息	消息只带 submissionId，判题机按 ID 回查
Anti-Corruption Layer	导入外部题库 JSON 格式千奇百怪	import 适配层翻译成内部领域模型

Bulkhead 的直观图像：

改造前（共享一个连接池 50 连接）：
  读请求 500 ──┐
               ├──→ [连接池 50] ──→ MySQL
  写判题 500 ──┘      ↑ 写高峰把 50 个连接全占住，读请求饿死

改造后（水密舱隔离）：
  读请求 ──→ [读池 40] ──→ 从库     ← 写再慢，读照样通
  写请求 ──→ [写池 10] ──→ 主库     ← 写最多占 10 个连接，可控

跟着做

步骤 1：Bulkhead——Resilience4j 舱壁隔离

resilience4j:
  bulkhead:
    instances:
      readPath:
        max-concurrent-calls: 40        # 读舱壁容量
        max-wait-duration: 100ms        # 排队 100ms 拿不到就快速失败
      writePath:
        max-concurrent-calls: 10
        max-wait-duration: 50ms
  thread-pool-bulkhead:
    instances:
      judgeCallback:                    # 判题回调走独立线程池
        core-thread-pool-size: 4
        max-thread-pool-size: 8
        queue-capacity: 100

@Bulkhead(name = "readPath", type = Bulkhead.Type.SEMAPHORE)
public ProblemDTO getProblem(long id) { return cacheService.getProblem(id); }

@Bulkhead(name = "writePath", type = Bulkhead.Type.SEMAPHORE)
public long submit(SubmissionDTO dto) { return submissionService.submit(dto); }