Golang微服务部署无通用最优解，需按场景选择：公有云（如EKS/GKE/ACK）为主流路径，推荐Docker+Kubernetes多阶段构建与Probe深度检查；私有化部署须攻克镜像分发、网络策略与证书管理三大硬点；Serverless仅适用于短时无状态任务。
Golang微服务没有“通用最优解”，只有匹配场景的部署方式。公有云适合快速验证、弹性伸缩和免运维，私有化部署则必须解决镜像分发、网络策略、证书管理等底层问题。
用 Docker + Kubernetes 部署到公有云（如 AWS EKS / GCP GKE / 阿里云 ACK）
这是当前最主流、风险最低的路径，尤其适合从开发到上线节奏快的团队。
- 每个微服务打一个
Dockerfile，用多阶段构建（golang:1.22-alpine AS builder→scratch或alpine:latest），镜像体积通常压到 10–20MB - 所有服务统一用
docker build --platform linux/amd64 -t $REGISTRY/service-a:${{ github.sha }} .构建，避免 Apple Silicon 本地构建后推送到 x86 集群失败 - Kubernetes Deployment 中必须配置
livenessProbe和readinessProbe，但别只 GET/health—— 要检查数据库连接、gRPC server 是否注册完成、配置中心是否 ready，否则滚动更新时流量会打到未就绪实例 - 公有云平台自带托管控制平面（如 EKS control plane 不需你维护），但你要负责 Node Pool 的 OS 补丁、kubelet 升级、CNI 插件兼容性（比如 Calico vs Cilium 在不同版本 K8s 下的行为差异）
私有化部署时绕不开的三个硬点
不是“能不能跑起来”，而是“能不能稳定交付”。很多团队卡在第二周——镜像拉不下来、服务间 DNS 解析失败、健康检查反复重启。
-
registry必须自建或对接企业级镜像仓库（如 Harbor），且所有节点要配置insecure-registries或正确部署 TLS 证书；否则docker pull直接报x509: certificate signed by unknown authority - 集群网络必须打通：Kubernetes Service 的 ClusterIP 默认不可跨节点访问，私有环境若没配好 CNI（比如 Flannel host-gw 模式下没开
iptables FORWARD链），服务间调用会超时 - 配置注入不能靠
ConfigMap硬编码：私有客户环境端口、域名、证书路径千差万别，要用envFrom+valueFrom.secretKeyRef动态挂载，且启动脚本中必须校验os.Getenv("DB_HOST")是否为空，否则 panic 后容器反复 CrashLoopBackOff
Serverless 不是“不用管部署”，而是换了一种复杂度
Cloud Run / AWS Lambda / Azure Functions 支持 Go，但只适合无状态、短时任务型微服务（比如图片转码、 webhook 处理），不适合长连接、定时同步、依赖本地文件系统的服务。
立即学习“go语言免费学习笔记（深入）”；
- Cloud Run 要求进程监听
$PORT，且必须在 4 秒内响应 HTTP 请求，否则触发 cold start 延迟；Go 程序启动快，但若 init 里加载大模型或初始化 DB 连接池，很容易超时 - Lambda 的
go1.xruntime 已弃用，新项目必须用provided.al2自定义运行时，意味着你要自己打包bootstrap文件并处理上下文生命周期 —— 实际工作量不比写个 Dockerfile 少 - 所有 Serverless 平台都不支持
goroutine跨 invocation 存活，如果你在 handler 里启了个常驻 goroutine 做心跳或轮询，它会在请求结束后被强制回收，行为不可控
真正难的不是选哪种方式，而是把“环境差异”显式暴露出来：同一份代码，在公有云能自动发现 Consul 服务，在私有环境却连不上本地 etcd，往往是因为 GOOS、CGO_ENABLED、证书路径、DNS 策略这些细节没对齐。建议所有微服务启动时打印 os.Getenv("ENV"), runtime.Version(), os.Getpid()，出问题第一时间看日志里这些字段是否符合预期。
