3. 供应链全景架构：上游源站、中游镜像仓库、下游分发节点、客户端拉取链路

在评估 Quota 镜像供应链的容量水位之前，必须首先建立完整的供应链架构视图。镜像从构建到被客户端拉取，依次经过四个核心环节：上游源站、中游镜像仓库、下游分发节点以及客户端拉取链路。每个环节的容量瓶颈都会直接影响整体供应链的水位健康度。

3.1 供应链四层模型

我们将 Quota 镜像供应链抽象为四层模型，每一层承担不同的职责，并具有独立的容量特征：

3.2 上游源站：镜像生产的起点

上游源站是镜像供应链的生产端。当开发人员提交代码后，CI/CD 流水线触发镜像构建，生成的镜像 Blob 和 Manifest 被推送到中游镜像仓库。源站的容量瓶颈通常出现在以下三个维度：

• 构建并发数： 同时运行的构建任务数量受限于 CI 集群的节点资源和构建队列深度。当并发数超过阈值，构建任务将排队等待，延长镜像交付周期。
• 源站出口带宽： 构建完成后，镜像 Blob 需要从构建节点上传至镜像仓库。如果出口带宽不足，上传速度会成为瓶颈，尤其在推送大镜像（如 AI 模型镜像 > 10GB）时尤为明显。
• Blob 存储 IOPS： 源站通常使用对象存储作为构建缓存和临时存储。高并发读写场景下，存储 IOPS 可能成为限制因素，导致构建失败或超时。

3.3 中游镜像仓库：元数据与存储枢纽

镜像仓库是供应链的核心枢纽，负责存储镜像的元数据（Manifest）和层数据（Blob），并提供 API 供下游节点和客户端查询与拉取。中游仓库的容量水位评估需要关注以下关键指标：

镜像仓库的容量规划需要特别考虑 Manifest 的查询性能。当仓库中存储的镜像版本数量超过百万级时，数据库索引和缓存策略将直接影响拉取链路的首字节时间。

3.4 下游分发节点：就近加速的关键

下游分发节点（CDN 边缘节点、P2P 代理、Region 缓存代理）是供应链的加速层。它们通过缓存热镜像，减少对中游仓库的回源请求，降低客户端拉取延迟。分发节点的容量水位评估主要围绕以下三个维度：

1. 节点磁盘水位： 每个分发节点都有有限的缓存空间。当磁盘使用率超过 80% 时，缓存淘汰策略将频繁触发，导致热镜像被提前驱逐，增加回源率。
2. 回源带宽： 当节点缓存未命中时，需要从中游仓库回源拉取镜像。回源带宽是分发节点的关键瓶颈，一旦带宽打满，所有未命中请求将排队等待，拉取延迟急剧上升。
3. 连接数上限： 每个分发节点能同时维持的 TCP 连接数有限。在突发拉取场景（如大规模集群扩容）下，连接数可能瞬间打满，导致新连接被拒绝。

3.5 客户端拉取链路：最后一公里的挑战

客户端拉取链路是供应链的末端，也是最接近用户的一环。客户端（Docker/Containerd、Kubelet）从分发节点或镜像仓库拉取镜像，并在本地解压和加载。客户端侧的容量水位评估需要关注：

• 并发拉取数： 单个节点上同时拉取的镜像数量。如果并发拉取数超过容器运行时的限制（如 Docker 默认的 max-concurrent-downloads），会导致拉取队列堆积。
• 网络吞吐： 客户端所在主机的网络带宽。当多个 Pod 同时拉取大镜像时，网络吞吐可能成为瓶颈，影响其他业务的网络通信。
• 本地磁盘 I/O： 镜像层在解压和写入本地存储时，磁盘 I/O 压力会显著增加。对于使用 HDD 的节点，I/O 瓶颈尤为突出。

3.6 供应链容量水位评估的全局视角

在完成四层架构的逐层分析后，需要建立全局水位评估的视角。供应链的容量瓶颈往往不是单一环节的问题，而是多个环节相互影响的结果。例如：

• 当上游源站构建并发过高，导致镜像推送延迟，会间接增加中游仓库的存储压力。
• 当中游仓库的 Manifest 查询延迟升高，会直接导致下游分发节点的回源等待时间增加。
• 当下游分发节点的磁盘水位过高，缓存命中率下降，回源流量激增，最终传导至客户端拉取延迟。