【一场沟通中的冲突，让我放弃云效，决定自建】

🚀 客户不愿为按量云效买单？那我们就彻底放弃云效，用 Spug 构建自己的部署系统。

💥 项目背景 · 冲突起点

一开始，客户（品牌方）在预算方面非常明确：服务器费用采用年预算制，即每年初一次性充值，账户预留几千块用于运维开支。这本是一个合理的模式，足以覆盖基础资源成本。

于是我们在技术方案上引入了阿里云云效，用于优化构建效率，也事先获得了客户的理解与口头认可。

值得一提的是：云效虽然有免费额度模式，但在项目上线前 2-3 个月发版频率极高，远超其免费上限,但又必须变更为按量付费。这就导致费用迅速攀升，尤其在云效构建速度较慢（平均每次 5-10 分钟）的背景下，效率低、费用高的问题叠加显现。

平台的“按量收费”模式最终成为了品牌方眼中的雷区，成为这场冲突的引爆点。

但事情的转折发生在一次关于 ECS 实例续费的沟通中。

但一次关于 ECS 服务器费用的常规沟通中，客户态度发生了转折：

“你们又用了什么云效？这个费用谁同意的？”

客户愤怒指出按量计费费用并未提前沟通，尽管合同并未包含，但客户明确表态：

“我只认合同里的，云效的钱你们别想让我出！”

这一刻我意识到：任何依赖第三方平台、存在潜在成本浮动的技术方案，在客户视角都是“风险点”。

于是我们当即决策：重构发版体系，告别云效，转向自建的 Spug + Kubernetes 自动发布架构。

🧱 技术选型 · 为什么是 Spug？

✅ 开源可控：部署在内网，权限、资源全掌控

✅ 自定义脚本发布，适配我们已有的构建逻辑

✅ UI 操作简单，低代码运维友好

✅ 可集成钉钉、日志记录、变量模板等

🔨 实战落地 · 技术栈与发版流程全景

在放弃云效之后，我们用脚本完全重构了部署逻辑。这不仅是一次工具替换，更是一次交付能力的进化。

🧭 脚本功能概览：

步骤	描述	意义
🏗️ 构建阶段	使用 Maven 构建微服务，生成 jar 包	与 CI 解耦，保留灵活控制权
🐳 镜像构建	使用 Docker 构建并打 tag（含时间戳）	支持版本回溯，配合 ACR 做灰度
☁️ 镜像推送	推送至阿里云 ACR（公网用于 push）	支持 VPC 拉取，节省节点网络消耗
📦 拉取配置	拉取 GitLab 配置仓库（ConfigMap 源）	与 GitOps 模式接轨，配置版本化
🧾 动态 YAML 渲染	用 sed 替换变量，生成实际部署文件	保证镜像 tag 精准注入，部署一致性
📥 K8s apply & rollout	应用 YAML，自动重启 deployment	实现零人工介入的发布流程

下面是这套流程的完整脚本实现( 仅供参考)：

我们将原本依赖云效流水线的发版流程迁移到以下脚本中：

#!/bin/bash
#!/bin/bash
set -e

# 获取传入的参数
DEPLOY_ENV="$1"   # 第一个参数：环境（prod 或 test）
JDK_VERSION="$2"  # 第二个参数：JDK 版本（8 或 17）
NAMESPACE="$3"    # 第三个参数：Kubernetes 的命名空间

# 根据 JDK 版本选择 JDK
if [ "$JDK_VERSION" == "17" ]; then
  export JAVA_HOME=/opt/jdk-17.0.4
  export PATH=$PATH:/opt/jdk-17.0.4/bin:/opt/apache-mav