你还在手动传包、靠“共享盘”发版本？Artifact Registry 才是依赖管理的终局答案！
说个扎心的现实：
很多团队嘴上说“云原生”“DevOps”，
结果一到发布环节：
👉 还在用 U盘 / 网盘 / FTP 传包
👉 依赖版本靠人记
👉 哪个版本上线了，全靠群聊天记录
然后某天线上炸了：
- “这个 jar 是谁打的？”
- “依赖版本是多少？”
- “能不能回滚？”
👉 全员沉默。
这不是技术问题，这是依赖生命周期失控的问题。
🧠 一、什么是“二进制依赖生命周期”？
很多人以为 Artifact Registry 就是“存包的地方”。
不对，它本质上解决的是：
👉 从构建 → 存储 → 分发 → 使用 → 淘汰 的全生命周期管理
我们把这个过程拆开看：
| 阶段 | 传统方式 | 问题 |
|---|---|---|
| 构建 | 本地打包 | 不可追溯 |
| 存储 | NAS/网盘 | 无版本治理 |
| 分发 | 手动拷贝 | 易出错 |
| 使用 | 人工指定版本 | 混乱 |
| 淘汰 | 不删 | 越堆越多 |
👉 最终结果：
依赖 = 技术债的黑洞
🔍 二、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 的本质，不是存包，而是“控制系统复杂度”
如果你现在的状态是：
👉 依赖靠传
👉 版本靠记
👉 出事靠猜
那我建议你认真考虑一件事：
❗你缺的不是工具，而是一套“依赖治理体系”
