Go工作流引擎动态扩容需确保服务无状态、启动快、健康可探、退出可等待、指标可采集；暴露/healthz和/readyz接口，用http.Server+Shutdown优雅处理SIGTERM，状态存外部存储，暴露自定义Prometheus指标。
Go 语言本身不提供“动态扩容的工作流引擎”——你要的不是在 Go 里写个调度器去启停 goroutine，而是让工作流服务能被 Kubernetes 等平台安全、稳定、可观测地扩缩容。核心在于：服务无状态、启动快、健康可探、退出可等待、指标可采集。
暴露 /healthz 和 /readyz 接口，别让 K8s 把你当僵尸
Kubernetes 的 livenessProbe 和 readinessProbe 不是摆设。没这俩接口，新 Pod 启动后可能永远进不了流量池，或被反复重启。
-
/healthz只检查进程存活和本地依赖（如db.PingContext()），不查下游、不连 Redis、不发 HTTP 请求；返回200 OK+{"status":"ok"}即可 -
/readyz额外检查初始化完成度：配置是否加载完毕、gRPC server 是否已 Start、消息消费者是否注册成功；未就绪时返回503 Service Unavailable - 别用
http.ListenAndServe直接阻塞主线程；用http.Server实例 +Shutdown()才可控
监听 SIGTERM 并优雅关闭，否则缩容=丢请求
K8s 缩容时默认发 SIGTERM，不是 SIGINT。忽略它，进程会被 30 秒后强制 KILL（取决于 terminationGracePeriodSeconds）。
- 必须同时监听
os.Interrupt和syscall.SIGTERM，不能只捕获 Ctrl+C -
Shutdown()调用前，先通知工作流引擎停止接收新任务（比如关掉 HTTP handler、暂停 Kafka consumer group rebalance） - 用
sync.WaitGroup等待正在执行的 workflow 实例完成，超时建议设为 10–30 秒（和 YAML 中terminationGracePeriodSeconds对齐） - 别在 signal handler 里调
os.Exit()或log.Fatal()，会跳过 cleanup
避免本地状态，所有“上下文”外移到共享存储
工作流引擎最常踩的坑：把 workflow 实例状态存在内存 map 或全局 struct 里。一扩容，状态就分裂；一缩容，状态就丢失。
立即学习“go语言免费学习笔记（深入）”；
- 任务状态（running/paused/success/failed）、变量快照、重试计数，全部存到 PostgreSQL、Redis 或 etcd；不要用
sync.Map模拟持久化 - 定时器（如 delay task、timeout check）别用
time.AfterFunc；改用外部调度器（如 Quartz on DB、Temporal 的 timer service）或基于消息 TTL 的方案 - 工作流定义（DSL/YAML/JSON）走配置中心（etcd/viper watch），不硬编码或读本地文件
- 日志打结构化（
slog.With("workflow_id", id)），方便 Loki 按实例+ID 聚合追踪
暴露 Prometheus 指标，让 HPA 看懂你的“忙”
HPA 默认只看 CPU，但工作流引擎的瓶颈常在队列积压、pending tasks 数、平均 workflow duration——这些得自己暴露。
- 用
prometheus/client_golang注册自定义指标，例如：workflow_pending_tasks_total、workflow_duration_seconds_bucket - 在任务入队、开始执行、完成时分别
Inc()/Observe()，别只在 HTTP handler 里埋点 - KEDA 更适合消息驱动场景：如果 workflow 触发源是 Kafka topic，直接配
ScaledObject监控kafka_lag，比轮询指标更准 - 镜像务必多阶段构建（
golang:alpine编译 →scratch运行），启动时间压到 500ms 内，否则 HPA 扩容延迟高
真正卡住动态扩容的，从来不是代码写了多少行，而是某次缩容时没等完一个 long-running workflow 就被 kill，或是某个 sync.Mutex 锁住了所有实例的并发吞吐。这些细节不会报错，但会让扩容失效——你加了 10 个 Pod，QPS 却只涨了 10%。
