Go语言分布式框架仅在需跨节点协作、高并发、故障隔离或弹性伸缩时必要；盲目分布式会将单机问题升级为网络、时序与一致性问题；微服务必须通过etcd/Consul实现服务发现，推荐gRPC替代HTTP JSON通信；状态共享应优先由单一服务处理，跨节点协调宜用etcd CAS或Raft；K8s部署需正确处理SIGTERM、健康检查须探测真实依赖；分布式本质是设计约束而非部署形态。
Go 语言分布式框架不是“拿来就能跑”的通用胶水，它只在明确需要跨节点协作、高并发吞吐、故障隔离或弹性伸缩的场景里才真正必要。盲目上分布式，反而会把单机问题放大成网络、时序、一致性问题。
微服务拆分后必须解决服务发现和通信
当用 Gin 或 Echo 拆出用户服务、订单服务、库存服务后，它们不再能靠 localhost 直连。硬编码 IP/Port 会立刻失效，而手动维护服务列表不可持续。
- 必须引入服务注册中心：用
etcd或Consul，让每个服务启动时主动上报地址，下线时自动注销 - 客户端不能直连，得通过服务名查地址：比如调用
"order-service"，而不是"10.0.1.12:8080" - 推荐走
gRPC而非 HTTP JSON：序列化更紧凑、连接复用、天然支持流式和超时控制，grpc-go的拦截器还能统一加重试、熔断逻辑
状态共享必须区分读写路径与一致性边界
多个 Go 实例共用一份数据（如用户 session、库存余量）时，直接上 Redis 或数据库锁是常见但危险的做法——网络分区、超时、时钟漂移会让 SETNX 或 SELECT FOR UPDATE 失效。
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 优先把有状态操作下沉到单一服务内：比如库存扣减只由“库存服务”处理，其他服务发异步消息或 RPC 请求
- 若真需跨节点协调，别自己实现两阶段提交；用
etcd的CompareAndSwap或raft协议保障线性一致写入 - 读多写少场景，允许短暂不一致：用本地缓存 + TTL + 主动失效（如监听
etcdkey 变更），别强求实时
Kubernetes 部署时，Go 进程生命周期必须适配容器模型
在 K8s 里，go run main.go 启动的进程若没处理好 SIGTERM，会被强制 kill 导致请求中断、连接未关闭、临时文件残留。
立即学习“go语言免费学习笔记（深入）”；
- 必须监听
os.Interrupt和syscall.SIGTERM，收到信号后先关闭 HTTP server（带超时）、等待 goroutine 退出、再释放资源 - 健康检查端点（如
/healthz）不能只返回 “OK”，要真实探测依赖：DB 连通性、下游服务可达性、磁盘空间 - Liveness probe 别设太激进：Go 程序 GC 或大量 goroutine 启动时可能卡顿几秒，probe timeout 少于 5s 容易误杀
最常被忽略的一点：分布式不是部署形态，而是设计约束。一个没做幂等、没处理网络分区、没定义最终一致边界的 Go 服务，扔进 Kubernetes 或接上 etcd，只会让失败更难定位、恢复更慢。
