后端要不要学 Go？我一个 Java 老手转 Go + K8s 的落地记录

入行前几年一直写 JavaSpring 那套很熟。但这两年明显感觉到 Go 在招人市场越来越热公司也在推新服务用 Go。我去年花时间把 Go 和 K8s 捡起来从单体改造成微服务跑上了云原生那套。这篇就把心路历程、踩的坑和一些能落地的代码记下来给纠结要不要转的同学一个参考。先说结论Go 值得学但别冲动Go 这两年增速确实猛后端岗位里新项目优先 Go的倾向越来越明显。它最吸引人的地方是部署简单——编译出来就是个二进制文件直接扔服务器上就能跑不像 Java 要装 JRE、配一堆环境。加上并发模型优秀写高并发服务很顺手。但不是说 Java 不行Java 生态在复杂业务、中间件支持上仍然很稳。我的建议是如果你要搞云原生、微服务、高并发这些方向Go 是很好的选择如果你还在传统企业做业务系统Java 也完全够用。上了 Go 这条船K8s 基本是绕不开的因为 Go 程序天生就是为容器化的。装环境# 装 Go官方推荐用包管理或直接下载macOS 用 brewbrewinstallgo go version# 装 Kind本地跑 Kubernetes 最省事brewinstallkind第一步用 Go 写一个最小服务用一个很轻的 Web 框架 Gin写个简单的接口packagemainimport(net/httpgithub.com/gin-gonic/gin)funcmain(){r:gin.Default()r.GET(/api/hello,func(c*gin.Context){c.JSON(http.StatusOK,gin.H{message:hello from go})})r.Run(:8080)// 监听 8080}一行命令编译产物就是个可执行文件go mod init myapp go get github.com/gin-gonic/gin go build-omyapp../myapp访问http://localhost:8080/api/hello就能看到 JSON 返回。这就是部署简单的体现——编译完直接跑。第二步给它套个容器写个 Dockerfile把编译好的二进制塞进一个精简镜像里# 编译阶段 FROM golang:1.22 AS build WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED0 GOOSlinux go build -o myapp . # 运行阶段用个极小的基础镜像 FROM alpine:latest WORKDIR /root/ COPY --frombuild /app/myapp . EXPOSE 8080 CMD [./myapp]构建镜像dockerbuild-tmyapp:latest.这样打出来的镜像很小因为运行阶段只有那个二进制加个 alpine 基础镜像不像 Java 要带整个 JRE。第三步用 Kind 起一个 K8s 集群Kind 是跑在 Docker 里的 Kubernetes本地开发调试最方便kind create cluster然后写个部署文件deploy.yaml把服务跑起来apiVersion:apps/v1kind:Deploymentmetadata:name:myappspec:replicas:3selector:matchLabels:app:myapptemplate:metadata:labels:app:myappspec:containers:-name:myappimage:myapp:latestports:-containerPort:8080---apiVersion:v1kind:Servicemetadata:name:myapp-svcspec:selector:app:myappports:-port:80targetPort:8080部署命令kubectl apply-fdeploy.yaml kubectl get pods# 能看到 3 个副本在跑Deployment 里的replicas: 3就是起 3 个副本Service 负责把流量负载均衡到这几个副本上。这就是微服务 云原生最基本的形态容器封装 编排调度 服务发现。从单体到微服务我踩过的坑坑现象怎么解代码里写死 IP服务一重启就找不到对方用 Service 名访问让 K8s 做服务发现配置写在代码里环境一换就要重新编译用 ConfigMap / 环境变量管理配置没做健康检查服务挂了自己不知道加 liveness/readiness 探针副本数拍脑袋流量一来就崩用 HPA 按 CPU 自动扩容服务发现这个坑最关键。刚开始我在代码里写死了对端 IP结果 Pod 一重建 IP 就变了服务直接失联。正确做法是用 K8s 的 Service 名去访问比如上面那个myapp-svcPod 之间用这个名字互相访问K8s 会自动解析。实测对比指标单体Java微服务Go K8s镜像大小~300MB带 JRE~15MB冷启动时间~5s~0.3s副本扩容手动HPA 自动发布方式停服重启滚动更新不停机Go 程序的镜像和启动时间优势非常明显这在云原生场景里很值钱——POD 频繁重建时启动快意味着容错能力强。收个尾Go K8s 这套组合核心价值就俩字轻镜像小、启动快和稳K8s 帮你管理副本、故障恢复、滚动发布。如果方向是云原生、微服务很值得投入。但如果你只是想把业务跑起来Java 也完全没问题别被必须转的焦虑带着走。你转 Go 了吗还是打算转评论区说说你的想法。