你还在手动传包、靠“共享盘”发版本？Artifact Registry 才是依赖管理的终局答案！

说个扎心的现实：

很多团队嘴上说“云原生”“DevOps”，
结果一到发布环节：

👉 还在用 U盘 / 网盘 / FTP 传包
👉 依赖版本靠人记
👉 哪个版本上线了，全靠群聊天记录

然后某天线上炸了：

• “这个 jar 是谁打的？”
• “依赖版本是多少？”
• “能不能回滚？”

👉 全员沉默。

这不是技术问题，这是依赖生命周期失控的问题。

🧠 一、什么是“二进制依赖生命周期”？

很多人以为 Artifact Registry 就是“存包的地方”。

不对，它本质上解决的是：

👉 从构建 → 存储 → 分发 → 使用 → 淘汰 的全生命周期管理

我们把这个过程拆开看：

👉 最终结果：

依赖 = 技术债的黑洞

🔍 二、Artifact Registry 到底解决了什么？

一句话：

👉 让“依赖”变成“资产”，而不是“垃圾”

核心能力：

• ✅ 版本管理（immutable）
• ✅ 权限控制
• ✅ 生命周期策略（自动清理）
• ✅ 多格式支持（Docker / Maven / npm / PyPI）
• ✅ 与 CI/CD 深度集成

⚙️ 三、实战：用 Artifact Registry 管理依赖（核心流程）

我们直接从“一个真实发布流程”讲起。

1️⃣ 创建仓库（以 Docker 为例）

gcloud artifacts repositories create my-repo \
  --repository-format=docker \
  --location=asia-east1 \
  --description="My Docker Repo"

👉 核心点：

• 指定格式（docker / maven / npm）
• 指定区域（降低延迟）

2️⃣ 推送镜像（版本即资产）

docker build -t asia-east1-docker.pkg.dev/my-project/my-repo/app:v1.0.0 .

docker push asia-east1-docker.pkg.dev/my-project/my-repo/app:v1.0.0

👉 注意这个点：

❗版本号 = 唯一身份（不要再用 latest）

3️⃣ 在 CI/CD 中自动发布

以 GitLab CI 为例：

stages:
  - build
  - push

build:
  script:
    - docker build -t $IMAGE_TAG .

push:
  script:
    - docker push $IMAGE_TAG

👉 推荐做法：

• 用 commit hash / tag 作为版本号
• 禁止覆盖已有版本

4️⃣ 使用依赖（部署阶段）

docker pull asia-east1-docker.pkg.dev/my-project/my-repo/app:v1.0.0

👉 核心收益：

• 所有环境使用同一版本
• 不再“测试环境OK，线上炸了”

🚨 四、真正关键：生命周期策略（很多人忽略）

如果你只是“存”，那你只是换了个地方堆垃圾。

👉 真正的核心是：自动治理

生命周期策略示例

{
  "rules": [
    {
      "action": { "type": "DELETE" },
      "condition": {
        "age": "30d"
      }
    }
  ]
}

👉 含义：

• 超过30天的镜像自动删除

更高级策略

{
  "rules": [
    {
      "action": { "type": "DELETE" },
      "condition": {
        "tagState": "untagged",
        "age": "7d"
      }
    }
  ]
}

👉 删除：

• 没有tag的“垃圾版本”
• 7天后自动清理

💡 五、一个很多团队踩的坑

我见过一个团队：

• Artifact Registry 用了
• CI/CD 也打通了

但他们：

👉 每次都 push latest

结果：

• 回滚不可能
• 版本不可追溯
• 灾难恢复靠运气

正确姿势应该是：

app:v1.0.0
app:v1.0.1
app:v1.1.0
app:commit-abc123

👉 原则：

❗版本不可变（Immutable），永不覆盖

🧠 六、依赖治理的三个层次（认知升级）

如果你想把这件事做好，一定要理解这三层：

🥉 第一层：存储

• 有仓库
• 能上传下载

👉 初级阶段（大多数团队）

🥈 第二层：规范

• 命名规范
• 版本规范
• CI/CD集成

👉 开始有秩序

🥇 第三层：治理（关键）

• 生命周期策略
• 安全扫描
• 权限隔离
• 成本控制

👉 这才叫“平台能力”

🔥 七、我自己的一个真实感受

我做运维这些年，最深的一个体会是：

❗系统复杂不可怕，不可控才可怕

而依赖管理，恰恰是最容易失控的地方。

你可能有：

• Kubernetes
• 微服务
• 自动扩缩容

但如果你的依赖是：

👉 手动传
👉 版本混乱
👉 无法回滚

那你所有的“先进架构”，都是空中楼阁。

🚀 八、再往前一步：依赖 = 供应链安全

这两年为什么大家都在聊“软件供应链安全”？

因为：

👉 Log4j 事件
👉 开源依赖投毒
👉 恶意镜像

这些问题，本质都是：

👉 依赖不可控

Artifact Registry + 策略控制，可以做到：

• 镜像扫描（漏洞检测）
• 私有仓库隔离
• 白名单机制

🧾 最后说点掏心窝的话

很多人觉得：

👉 “依赖管理不重要，先把业务跑起来再说”

但现实是：

❗你迟早要为“混乱”付出代价

要么：

• 半夜回滚失败
• 要么：版本冲突炸系统
• 要么：安全漏洞全网爆

👉 真正成熟的团队是什么样？

不是技术多先进，而是：

• 每个版本可追溯
• 每个依赖可回滚
• 每个镜像有生命周期

🎯 一句话总结

👉 Artifact Registry 的本质，不是存包，而是“控制系统复杂度”

如果你现在的状态是：

👉 依赖靠传
👉 版本靠记
👉 出事靠猜

那我建议你认真考虑一件事：

❗你缺的不是工具，而是一套“依赖治理体系”