SAE Serverless 应用引擎实践：千里达票务系统非核心业务的容器化捷径
迁 ACK 的过程中发现一个现实问题：不是所有业务都值得上 K8s。管理后台、报表服务、客服工具这些非核心业务，团队花大量精力写 Deployment、HPA、Ingress，但业务量又不大。阿里云 SAE（Serverless 应用引擎）把 K8s 封装成 PaaS，不用管集群，上传代码或镜像就能跑，按 vCPU/内存秒级计费。
一、ACK vs SAE 怎么选
- ACK：核心交易链路，要全量 K8s 能力、弹性策略复杂；
- SAE：非核心业务，要的是"传上去就能跑，按调用量付钱"。
二、迁到 SAE 的服务
- 运营后台（管理端）；
- 报表导出任务；
- 客服工单系统；
- 内部定时跑批。
三、关键实现
3.1 部署方式
- 打包成 Jar/War 上传；
- 或直接关联 ACR 镜像；
- 配好 CPU/内存/实例数（最少 1，最多 10）；
- 自动配好 SLB、日志、监控。
3.2 弹性策略
按 QPS 自动扩缩，也可以按 CPU。闲时缩到 0 实例（彻底不花钱），有请求自动拉起——内部工具完全够用。
3.3 配置与密钥
SAE 内置配置中心，数据库密码不写镜像里，启动时注入环境变量。
四、踩坑复盘
- 冷启动：缩到 0 后第一个请求要等 10 秒。解决：内部工具接受，核心业务不用；
- 本地文件：早期代码写日志到本地磁盘，Pod 重启就丢。解决：日志统一打 SLS；
- 端口约定：SAE 默认读 8080，我们的服务跑在 9090。解决：启动命令显式指定；
- 定时任务：多副本时定时任务重复跑。解决：用 SAE 的定时触发器功能，或选单机部署。
五、效果与总结
SAE 让小团队不用为每个内部服务都维护一套 K8s YAML。对千里达票务系统这种核心业务上 ACK、外围业务上 SAE 的组合，是当前阶段最划算的混合架构。
