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{})。
服务间通信：HTTP/JSON 是起点，gRPC 是收敛点
初期用 net/http + JSON 快速验证业务流没问题，但很快会遇到三类问题：结构体字段类型丢失（如 int64 变成 float64）、无内置超时控制、错误码语义模糊（全塞在 HTTP 状态码里）。
上线前应切换到 gRPC，理由很实际：
