Golang微服务是围绕业务边界、通信契约、生命周期自治和可观测性构建的协作体系，需避免隐式依赖、上下文丢失、数据库连接爆满、gRPC超时等运维黑洞。
Golang微服务不是“把代码拆成多个 main.go 就完事”，而是围绕业务边界、通信契约、生命周期自治和可观测性构建的一套协作体系。没设计好，后期会陷入服务间隐式依赖、日志查不到上下文、扩容后数据库连接爆满、gRPC 调用莫名超时等典型运维黑洞。
服务拆分不能只看功能名，要看数据所有权和变更频率
一个叫 user-service 的服务，如果同时读写订单表、缓存用户积分、又调用短信网关发验证码，那它大概率已违背“单一职责”。真正健康的拆分应满足：
- 每个服务拥有自己专属的数据库（哪怕只是逻辑隔离），不直连其他服务的表
- 表结构变更只影响本服务，例如改
users.status字段类型，不应导致order-service编译失败或运行时 panic - 同一业务实体（如
User）在不同服务中应是投影（DTO），而非共享 model 包——共享包等于强耦合
常见错误：用一个 shared/models Go module 放所有 struct，结果改个 Product.Name 类型，10 个服务全得重新测试上线。
HTTP 和 gRPC 不是“选一个”，而是按角色分层用
对外暴露 API（给 Vue/React、第三方系统、App）必须用 HTTP/JSON；服务内部高频调用（如 order-service 查 user-service 的实名认证状态）必须用 gRPC。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 层用
Gin或Go-Zero做路由和鉴权，返回200 OK+ JSON，前端直接消费 - gRPC 层用
protoc-gen-go-grpc生成 stub，定义.proto文件约束输入输出，避免 “字段拼错”、“类型不一致” 这类低级但难 debug 的问题
示例陷阱：有人把 gRPC service 直接注册到公网入口，结果 curl 报错 HTTP/2 stream error: stream ID 1; PROTOCOL_ERROR——因为浏览器根本不支持原生 gRPC over HTTP/2，必须走 gateway 转换。
服务注册不是“启动时 ping 一下注册中心就结束”
Consul 或 etcd 上看到服务健康状态为 passing，不代表它真能干活。常见失效场景包括：
- 服务启动成功，但数据库连接池未初始化完成，第一个请求就
timeout - 注册心跳间隔设为 30s，但网络抖动持续 45s，实例被误剔除
- 服务优雅退出时没调用
consul.Agent.ServiceDeregister，残留的“僵尸实例”持续接收流量
正确做法是：在注册前执行轻量级就绪检查（比如 ping 数据库、验证 Redis 连通性），并用 viper 动态加载注册地址、超时、重试次数；退出时用 os.Interrupt 捕获信号，先停 listener，再注销，最后 close db。
日志、链路、指标三者缺一不可，且必须打通上下文
只打 log.Printf("user %d updated") 是无效日志。分布式环境下，你根本不知道这条日志来自哪个请求、哪个 trace、哪个实例。
- 日志必须带
request_id（从 HTTP header 注入）和span_id（OpenTelemetry 生成） - 所有 gRPC client 必须加
otelgrpc.Interceptor()，HTTP handler 加otelhttp.NewMiddleware() - Prometheus 指标要暴露
/metrics，且每个服务自增自己的http_request_duration_seconds_bucket，别指望网关统一埋点——网关看不到服务内部 DB 查询耗时
最容易被忽略的是：跨服务调用时，context 没传递 traceID。比如 order-service 调 user-service 的 gRPC，没把 ctx 传进去，整个链路就断了。结果就是：前端报错，你查 order 日志看到 “failed to get user”，再查 user 日志——空的，因为没 traceID，日志系统压根没聚合。
微服务真正的复杂度不在代码量，而在各服务间的隐式契约：谁负责重试、谁处理幂等、谁兜底降级、日志怎么对齐、配置怎么热更新。这些细节不提前约定，跑通第一个接口只是幻觉。