3. 制品分发架构概述：制品仓库、分发节点、CDN、负载均衡器的基础架构
制品分发失败的原因往往隐藏在架构的每一层。理解从制品仓库到最终用户的完整链路，是快速定位故障的前提。本章将拆解分发架构的四个核心组件：制品仓库、分发节点、CDN 与 负载均衡器，并梳理它们之间的数据流与依赖关系。
3.1 核心组件与职责
一个标准的生产级制品分发系统，通常由以下四个层次构成。每一层都有明确的职责和潜在的故障模式。
| 组件 | 核心职责 | 典型技术选型 | 常见故障模式 |
|---|---|---|---|
| 制品仓库 | 存储与版本管理制品（JAR、Docker 镜像、npm 包等） | Nexus、Artifactory、Harbor、AWS ECR | 磁盘写满、元数据损坏、认证超时 |
| 分发节点 | 从仓库拉取制品并缓存到本地，作为下游的源站 | 自建 Nginx 缓存、S3 网关、CloudFront 源站 | 缓存过期策略错误、磁盘 I/O 瓶颈、连接池耗尽 |
| CDN | 边缘缓存与加速，降低源站压力，提升用户下载速度 | CloudFront、Akamai、阿里云 CDN、Cloudflare | 缓存未命中、回源超时、SSL 证书过期 |
| 负载均衡器 | 流量分发、健康检查、故障转移 | Nginx、HAProxy、AWS ALB/NLB、F5 | 后端节点宕机、健康检查配置错误、会话保持失效 |
架构视角： 制品仓库是“最终一致性”的存储后端，而分发节点和 CDN 是“高性能缓存”层。负载均衡器则负责将用户请求均匀分配到多个分发节点或 CDN 边缘节点上。
3.2 分发架构数据流
下图展示了制品从上传到下载的完整路径。理解这个流向，有助于在故障时快速判断“断点”出现在哪一层。
关键路径分析：
- 正常下载路径： 用户 → 负载均衡器 → CDN 边缘节点 → 分发节点（缓存命中） → 返回制品。
- 回源路径： CDN 边缘节点未命中 → 回源到分发节点 → 分发节点未命中 → 回源到制品仓库。
- 故障放大效应： 如果分发节点缓存大面积失效，所有请求将穿透到制品仓库，导致仓库 I/O 飙升，引发雪崩。
3.3 负载均衡器在分发中的特殊角色
负载均衡器并非简单的流量分发器。在制品分发场景中，它承担了三个关键任务：
- 健康检查与自动摘除： 定期探测后端分发节点或 CDN 源站的 80/443 端口。一旦发现响应超时或 5xx，自动将故障节点从转发池中移除。
- 会话保持（可选）： 对于大文件断点续传场景，需要将同一用户的请求始终转发到同一后端节点，避免分片重组失败。
- 流量灰度与权重分配： 在新版本制品上线时，通过权重将小比例流量引向新版本分发节点，验证稳定性后再全量切换。
常见陷阱： 负载均衡器的健康检查配置过于宽松（例如检查间隔 30 秒、超时 10 秒），会导致后端节点已经宕机 30 秒后，LB 才将其摘除。这 30 秒内所有请求都会失败。建议将检查间隔设为 5 秒，超时设为 2 秒，不健康阈值设为 2 次。
3.4 CDN 缓存策略与失效模式
CDN 是分发架构的“第一道防线”。它的缓存策略直接影响用户体验和源站压力。
| 缓存策略 | 配置方式 | 对分发的影响 |
|---|---|---|
| 强制缓存 | 通过 Cache-Control: max-age=3600 控制 | 用户直接命中 CDN 边缘节点，速度最快；但更新后需要等待缓存过期 |
| 协商缓存 | 通过 ETag / Last-Modified 回源校验 | 每次请求都会回源校验，但只有文件变化时才传输完整内容；适合频繁更新的小文件 |
| 目录/正则刷新 | 手动调用 CDN API 刷新缓存目录 | 用于紧急修复：当错误制品被分发后，立即刷新所有边缘节点的缓存 |
最佳实践： 对于制品分发，建议对
*.jar、*.tar.gz 等大文件设置较长的强制缓存（如 24 小时），并在 CI/CD 流水线中自动触发 CDN 缓存刷新。对于 metadata.xml 等元数据文件，使用协商缓存，确保客户端能及时获取最新版本列表。
3.5 架构拓扑总结
下图将上述组件整合为一个完整的逻辑拓扑，展示请求从客户端到最终存储的完整链路，以及各层之间的冗余与故障隔离机制。
架构设计要点：
- 冗余： 每一层都至少部署 2 个实例，避免单点故障。
- 故障隔离： CDN 边缘节点之间相互独立，一个节点故障不影响其他区域。
- 回源保护： 分发节点应启用“降级模式”——当制品仓库不可用时，返回缓存中的旧版本制品，而不是直接返回 502。
- 监控覆盖： 对每一层的关键指标（缓存命中率、响应延迟、错误率）设置告警，确保在用户感知之前发现异常。