go 微服务关键在避坑：grpc 适合内部通信但需注意跨语言兼容性，http/json 更适对外api；etcd 服务发现须实现租约续期与 watch 监听；kitex 轻量适配已有基建，kratos 全面但勿混用；goroutine 必须受 context 控制并限流。
Go 语言做微服务，不是“能不能”，而是“怎么避免掉进坑里”。它确实适合——但前提是清楚哪些组件必须自己搭、哪些能交给生态、哪些看似省事实则埋雷。
gRPC vs HTTP/JSON：选错协议，后期改起来像重写
别只看文档说“gRPC性能好”就默认选它。真实场景中，gRPC 要求客户端和服务端都用兼容的 protobuf 版本，跨语言调用时需生成对应 stub，调试时看不到原始请求体；而 HTTP/JSON（比如用 Gin 或 Echo）直接 curl 就能测，前端直连也方便。
实际建议：
- 内部服务间通信（如订单服务调库存服务），优先用
gRPC：二进制序列化 + 流控 + 内置健康检查，Kitex或gRPC-Go都可开箱即用 - 对外暴露 API（如给 Web 或 App 调用），坚持用
HTTP/JSON：加一层gateway（如grpc-gateway）把gRPC接口转成 REST，别手写两套逻辑 - 别混用：同一个服务既暴露
gRPC端口又暴露HTTP端口，会放大路由、鉴权、日志格式不一致的问题
服务注册与发现：etcd 不等于开箱即用
很多教程写几行 clientv3.Put 就算完成注册，但生产环境真正卡住的是续租、监听、故障剔除这三步。
etcd 的 key 默认是临时租约（lease），不主动 KeepAlive，服务挂了也不会自动下线；消费者如果只做一次 Get，后续实例增减完全感知不到。
实操要点：
- 注册时必须绑定
Lease，并启动 goroutine 定期调用Lease.KeepAlive - 发现端要用
Watch监听目录变更，而不是轮询Get—— 否则扩容新实例要等几十秒才生效 - 务必实现健康检查 fallback：当 etcd 不可用时，本地缓存最近一次获取的服务列表，避免雪崩
- 别把服务名硬编码成
/services/order-svc，用环境变量注入，比如$(SERVICE_NAME)
Kitex 和 Kratos：框架不是银弹，选错反而拖慢迭代
Kitex 和 Kratos 都是成熟框架，但定位不同：Kitex 是“高性能 RPC 框架”，核心是协议和传输层优化；Kratos 是“应用框架”，自带配置、日志、熔断、链路追踪等模块，但抽象层略重。
判断依据很简单：
- 如果你的团队已有统一的日志中心、配置中心、监控体系，选
Kitex更轻量，只补 RPC 缺口 - 如果你从零开始、人手少、想快速上线 MVP，
Kratos的kratos new脚手架能直接生成带 tracing 和 config 的骨架 - 千万别在
Kratos项目里手动引入Kitex的 transport —— 两者对 context 和 middleware 的处理逻辑冲突，会导致span断链或超时失效
并发模型误用：goroutine 泛滥比锁竞争更难排查
Go 的 goroutine 看似廉价，但每个默认栈 2KB，10 万个就是 200MB 内存；更麻烦的是，无节制启 goroutine + 忘记 select 超时，会让服务在低 QPS 下突然 OOM 或卡死。
典型错误场景：
- 在 HTTP handler 里直接起 goroutine 处理业务（如发 MQ、写 DB），没设 context deadline，上游已断连，goroutine 还在跑
- 用
for range遍历 channel 时没加退出条件，channel 关闭后仍空转消耗 CPU - 用
sync.WaitGroup等待大量 goroutine，但忘记Done()或 panic 导致 wg 一直阻塞
安全做法：所有非 trivial 的 goroutine 都包一层带 ctx.Done() 检查的 wrapper；批量任务用 worker pool 控制并发数，别用 runtime.GOMAXPROCS 去“调优”——它控制的是 OS 线程数，不是 goroutine 数。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
