keda 不需修改 go 代码，因其伸缩决策完全基于外部事件源（如 rabbitmq 队列长度、prometheus 中 rocketmq 延迟指标），通过 hpa 间接控制 go 应用副本数；go 服务仅需满足快速就绪（/readyz 返回 200）和优雅终止（sigterm 后调用 http.server.shutdown）即可。
KEDA 不是“引入到 Golang 集群”里的组件——它运行在 Kubernetes 集群上，和你的 Go 服务无关；Go 服务只是被 KEDA 控制的 Deployment，不参与 KEDA 的安装、配置或指标拉取逻辑。
为什么 KEDA 不需要改 Go 代码
KEDA 的伸缩决策完全基于外部事件源（如 RabbitMQ 队列长度、Prometheus 中的 RocketMQ 消费延迟）；它通过 HorizontalPodAutoscaler 间接控制你的 Go 应用副本数。Go 服务本身只需满足两个前提：
- 能快速启动并返回
200给/readyz探针（不能卡在 DB 连接池初始化） - 收到
SIGTERM后调用http.Server.Shutdown()，等待正在处理的请求完成（建议 timeout ≤ 30s）
你不需要在 Go 里 import KEDA、暴露指标接口、或轮询队列长度——这些全由 KEDA 的 scaler 和 trigger 完成。
对接 RabbitMQ 时最常卡住的三件事
不是 Go 写得不对，而是 KEDA 找不到 RabbitMQ 的队列数据：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
TriggerAuthentication中填的用户名/密码必须是 RabbitMQ 管理插件的账号（不是应用连接用的普通用户），且该账号需有monitoring权限 - RabbitMQ 的管理端口
15672必须对 KEDA 所在命名空间的 Pod 网络开放（Service 或 NetworkPolicy 限制常被忽略） -
ScaledObject.spec.triggers[0].metadata.queueName必须和实际队列名**完全一致**（包括大小写），且若用了 vhost，必须显式指定vhost参数，否则默认查/
对接 RocketMQ 必须走 Prometheus 桥接
RocketMQ 没有原生 HTTP API，KEDA 无法直连。必须先部署 rocketmq-exporter，把 rocketmq_group_get_latency_max 这类指标暴露给 Prometheus，再让 KEDA 的 PrometheusScaler 查询：
- 确认
rocketmq-exporter已采集到目标 Group 的堆积延迟，并能在 Prometheus UI 查到对应时间序列 -
ScaledObject中query字段要写成 PromQL 表达式，例如：sum(rocketmq_group_get_latency_max{group="keda"}) - 注意
metricName是你自定义的名称（如rocketmq_lag），不是 Prometheus 原始指标名
KEDA 版本升级后容易漏掉的身份验证变更
KEDA ≥ v2.15 已移除 Pod Identity 支持，强制使用 Workload Identity（Azure）或 OIDC-based TriggerAuthentication（其他平台）。如果你还在用旧版 podIdentity: 配置，升级后会报错 failed to resolve auth provider：
- Azure 用户：必须先启用 AKS 的
workload-identityaddon，再绑定ServiceAccount到 Entra ID 应用 - 非 Azure 用户：改用
secretRef或env注入认证凭据，避免硬编码在 YAML 里 - 检查
kubectl get triggerauthentications.keda.sh -A输出中是否还有type: podIdentity字段
真正麻烦的不是写 Go，而是让 KEDA 能稳定拿到指标——网络、权限、命名一致性，这三个点卡住 80% 的上线问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
