容器化改造实践：千里达票务系统在阿里云 ACK 上的部署与弹性伸缩
随着景区数量增加，千里达票务系统的模块越来越多，传统"一台 ECS 装全套"的部署方式迭代慢、扩容笨重。我们把核心服务迁移到阿里云容器服务 ACK，实现了标准化交付与秒级弹性伸缩，本文分享改造过程与踩坑经验。
一、为什么容器化
- 模块化演进：订单、票务、会员、渠道分销拆分为独立服务，各自独立发布；
- 快速扩容：节假日高峰应用层需快速扩副本，容器化后一条命令完成；
- 环境一致性：开发、测试、生产同一套镜像，告别"在我机器上是好的"。
二、方案设计
代码 → Docker镜像(镜像仓库) → ACK集群(Deployment) → HPA弹性 → Ingress接入
- 镜像仓库：使用阿里云容器镜像服务（ACR），支持镜像扫描与自动构建；
- 弹性伸缩：HPA 按 CPU 或自定义指标自动扩缩副本，设置最小 2 / 最大 20；
- 接入层：Ingress 统一入口，配套 SLB 提供公网接入。
三、关键实现
3.1 Deployment 示例
apiVersion: apps/v1
kind: Deployment
metadata:
name: ticket-order
spec:
replicas: 4
selector:
matchLabels: {
app: ticket-order }
template:
spec:
containers:
- name: order
image: registry.cn-hangzhou.aliyuncs.com/ticket/order:1.4.2
resources:
requests: {
cpu: "1", memory: "2Gi" }
limits: {
cpu: "2", memory: "4Gi" }
readinessProbe:
httpGet: {
path: /healthz, port: 8080 }
3.2 HPA 配置
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: ticket-order-hpa
spec:
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target: {
type: Utilization, averageUtilization: 70 }
四、踩坑复盘
- 优雅停机没配：发布时老 Pod 被直接杀掉，正在处理的请求 502。解决：配置 preStop 等待 + readiness 探针延迟摘流量；
- 资源配额拍脑袋：limits 设得太小导致 OOMKilled 重启循环，设得太大又浪费。解决：按压测数据反推 request/limit，并监控实际用量迭代；
- 镜像拉取慢：高峰期新扩 Pod 拉镜像排队，扩不动。解决：节点预热镜像 + ACR 加速 + 合理设置镜像拉取策略；
- 有状态服务误容器化：把定时任务也放进 Deployment，多副本重复执行。解决：定时任务单独用 Job/CronJob 声明。
五、效果与总结
容器化后，千里达票务系统应用层实现了"秒级扩容、分钟级发布"，节假日高峰从容应对。ACK 让团队把精力从"运维服务器"转向"维护业务"。容器化是千里达票务系统迈向云原生的重要一步，也为后续多云部署、灰度发布打下基础。
