Go不提供微服务架构，只提供工具链；需按业务能力（非功能模块）划分服务边界，用DDD限界上下文界定职责；通信应从HTTP/JSON收敛至gRPC以保障类型安全与错误语义；服务发现推荐Consul+grpc-go内置集成；可观测性须上线即具备，统一traceID贯穿日志、指标、链路。
Go 本身不提供“微服务架构”这个东西，它只提供构建微服务的工具链；真正决定架构是否成立的，是服务拆分边界、通信协议、服务发现、错误处理和可观测性设计——不是 go run 能跑起来就算微服务。
怎么定义服务边界：别按功能模块切，按业务能力切
常见错误是把“用户管理”“订单管理”当成服务名，结果所有逻辑堆在 UserService 里，连支付回调、地址校验、实名认证都往里塞。这本质是单体换壳。
正确做法是用 DDD 的限界上下文（Bounded Context）来识别：一个服务只负责一个明确的业务能力，且拥有自己的数据存储和生命周期。比如：
-
UserProfileService：只管头像、昵称、性别等展示型字段，不碰密码、登录态 -
AuthnService：只处理登录、登出、token 签发与校验，不存用户资料 -
AddressValidationService：只做第三方地址清洗和标准化，不参与下单流程
每个服务对外暴露的接口必须窄——例如 ValidateAddress(ctx, req *ValidateRequest) (*ValidateResponse, error)，而不是 DoEverything(ctx, data interface{})。
立即学习“go语言免费学习笔记（深入）”；
服务间通信：HTTP/JSON 是起点，gRPC 是收敛点
初期用 net/http + JSON 快速验证业务流没问题，但很快会遇到三类问题：结构体字段类型丢失（如 int64 变成 float64）、无内置超时控制、错误码语义模糊（全塞在 HTTP 状态码里）。
上线前应切换到 gRPC，理由很实际：
-
protoc生成强类型客户端和服务端，编译期就能发现字段不一致 -
grpc.DialContext默认带连接池和重试策略，不用自己手写http.Client保活逻辑 - 错误统一走
status.Error，客户端可用status.Code(err)直接判断CodeNotFound或CodeDeadlineExceeded
示例：定义一个简单方法后，生成的 Go 接口天然支持 context 传递和 deadline 控制，不需要额外封装。
服务注册与发现：别自己轮询 etcd，用 Consul + grpc-go 的内置集成
很多团队花两周写 etcd watcher + 健康检查心跳，最后发现 grpc.WithResolvers 配合 Consul 的 DNS SRV 记录就能自动实现服务发现。
关键配置只有两处：
- 启动服务时向 Consul 注册：
consul.Agent.ServiceRegister(&consul.AgentServiceRegistration{...}) - 客户端 Dial 时启用 DNS 解析：
grpc.Dial("dns:///userprofile.service.consul:9090", grpc.WithResolvers(consulResolver))
Consul 自带健康检查（HTTP GET /health），失败服务自动从 DNS 列表剔除，grpc 客户端下次请求会跳过该节点——整个过程对业务代码透明。
可观测性不是锦上添花，而是上线第一小时就该有的能力
没有日志上下文追踪的服务，等于在黑盒里修电路。Go 生态里最轻量可行的组合是：
- 日志：用
zap+context.WithValue注入 traceID，避免每层函数都传ctx和logger两个参数 - 指标：用
prometheus.ClientGolang暴露http.Handle("/metrics", promhttp.Handler())，核心只埋 3 个指标：请求量（Counter）、延迟（Histogram）、错误率（Counter with label="error_type"） - 链路：用
go.opentelemetry.io/otel初始化全局 tracer，gRPC server interceptor 自动注入 span，不用改业务 handler
最容易被忽略的是：所有日志行必须带 traceID，所有 HTTP/gRPC 返回头必须带 X-Trace-ID，否则前端报错时你根本没法串联请求流。
