golang做分布式微服务的核心是守住「通信可控、注册可查、失败可降、链路可观」四条线：注册发现必须用etcd/consul；通信优先grpc并配超时；熔断用gobreaker+本地fallback；可观测性从首服务埋点，统一opentelemetry+zerolog+prometheus。
直接上结论：Golang 做分布式微服务，核心不是选框架，而是守住「通信可控、注册可查、失败可降、链路可观」四条线。go-zero、Micro、etcd + grpc 手写都行，但绕不开这四个动作。
服务注册与发现必须用 etcd 或 Consul，别碰自建文件/DB 方案
本地文件或 MySQL 存服务地址看着简单，上线后立刻崩——无法自动剔除宕机实例、不支持 TTL 续约、客户端轮询无负载感知。
-
etcd是当前 Go 生态最稳的注册中心：clientv3客户端成熟，Grant+KeepAlive可靠支撑租约，WithPrefix查询天然适配服务名前缀（如/services/order/） - 注册时 key 格式必须带
service-name和instance-id，例如/services/user/7f9a2b3c，否则Discover无法按服务聚合 - 别在
Register里做重试逻辑——etcd 写失败应直接 panic 或 abort 启动，避免注册状态不一致；健康检查由 Watch 通道 + 心跳维持更可靠
服务间通信优先用 gRPC，HTTP 仅限对外暴露
gRPC 不只是“性能好”，它强制契约（.proto）、自带超时/元数据/流控，而 HTTP+JSON 在服务间调用时容易失控：字段类型模糊、错误码随意、header 传递难统一。
- 所有内部服务调用必须走
grpc-go，且每个ClientConn配WithBlock()+WithTimeout()，避免连接卡死 - 用
grpc-gateway暴露 REST 接口，而不是另起一套net/httphandler——同一份.proto同时生成 gRPC Server 和 HTTP Proxy，契约不撕裂 - 禁止在 gRPC 请求体里传大 JSON 字段（如原始 HTML），改用
bytes或分片上传；否则 protobuf 编解码耗时飙升，压垮 CPU
熔断降级别依赖中间件，用 gobreaker + 本地 fallback 就够
像 go-zero 的内置熔断看着省事，但配置项藏太深，出问题时连开关在哪都找不到。生产环境更需要“一眼看清、一招生效”的控制力。
- 直接引入
github.com/sony/gobreaker，初始化时设MaxRequests: 1、Interval: 30 * time.Second、Timeout: 60 * time.Second，策略清晰可推演 - 降级逻辑必须写在调用点附近，比如
userClient.GetProfile(ctx, req)失败后，立刻 return&UserProfile{Avatar: "default.png"}，而不是抛 error 让上层兜底 - 关键路径（如支付下单）禁用全局熔断器，改用
context.WithDeadline+select超时分支做硬性 fallback，避免熔断器状态污染其他请求
可观测性从第一个服务就埋点，别等上线再补
日志没 trace_id、指标没 service 标签、链路没 span 关联——等于在分布式系统里闭眼开车。这些不是“锦上添花”，是故障定位的底线。
- 所有 HTTP/gRPC 入口加 OpenTelemetry 中间件，自动注入
trace_id和span_id，并透传到下游 context；用otelhttp和otelgrpc包，别手写 - 日志统一用
zerolog，每条 log 必带service、trace_id、level字段，输出为 JSON，不拼字符串 - 指标暴露路径固定为
/metrics，用prometheus/client_golang注册，至少采集：http_request_duration_seconds（按 path 和 status 分组）、grpc_server_handled_total（按 method 和 code）、自定义错误计数器（如user_repo_save_failed_total）
最容易被忽略的其实是服务边界——很多团队把“拆成多个 Go 进程”当成微服务，结果共用一个数据库事务、共享 config struct、跨服务直接调函数。真正的分布式微服务，必须每个服务有独立的 DB schema、独立的部署单元、独立的可观测 endpoint，否则治理能力全失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
