Go微服务核心是职责分离与标准通信：gRPC用于高性能服务间调用，HTTP/REST用于对外暴露；需按DDD分层、逻辑隔离数据库、避免直连对方DB；配合服务发现、结构化日志与指标监控。
用 Go 构建微服务，核心是“职责分离 + 标准通信”。gRPC 适合服务间高性能调用，HTTP（如 REST）更适合对外暴露或前端对接。两者不冲突，常共存于同一服务中。
定义清晰的服务边界
别一上来就拆。先从单体里识别高内聚、低耦合的业务域，比如用户管理、订单处理、库存校验。每个域独立部署、独立数据库（哪怕初期共用 schema，也要逻辑隔离）。Go 的模块化（go mod）天然支持按服务组织代码仓库，一个服务一个 repo 或一个 repo 下多个 service 目录均可。
- 用 domain-driven design（DDD）术语命名包：如 user/domain、order/application
- 每个服务至少包含：API 层（gRPC/HTTP handler）、应用层（use case）、领域层（entity、repo interface）、基础设施层（DB、cache 实现）
- 避免跨服务直接访问对方数据库——必须走 API
用 gRPC 实现服务间通信
gRPC 基于 Protocol Buffers，天生支
持多语言、流式传输、强类型契约。Go 生态对 gRPC 支持极好。
- 在 api/proto 下定义 .proto 文件，例如 user_service.proto，声明 service 和 message
- 用 protoc --go_out=. --go-grpc_out=. *.proto 生成 Go 代码（需安装 protoc-gen-go 和 protoc-gen-go-grpc）
- 服务端实现生成的 UnimplementedUserServiceServer 接口；客户端用 grpc.Dial 连接，调用生成的 client 方法
- 加中间件：用 grpc.UnaryInterceptor 统一处理日志、认证、超时（如 context.WithTimeout）
用 HTTP/REST 对外暴露能力
前端、第三方系统或调试场景更习惯 HTTP。Go 标准库 net/http 足够轻量，也可选 gin、echo 提升开发效率。
- HTTP handler 不直接写业务逻辑，而是转调本地的 application service 或通过 gRPC 调用其他服务
- 用结构体绑定请求（json.Unmarshal 或 gin 的 c.ShouldBindJSON），返回标准 JSON 响应（含 status code、error detail）
- 对外接口做版本控制，如 /v1/users；内部 gRPC 接口可不暴露版本，靠 proto 兼容性演进
- 用 gorilla/mux 或 gin 的路由分组管理不同资源路径，配合中间件统一鉴权（如 JWT 解析后注入 context）
服务发现与可观测性起步
微服务多了，硬编码地址不可行。初期可用 Consul 或 etcd 做服务注册/发现；Go 客户端如 hashicorp/consul-api 很容易集成。
- 服务启动时向注册中心注册自身地址和健康检查端点（如 /health）
- gRPC 客户端使用 resolver.Builder 集成服务发现，替代固定 endpoint
- 必加日志：用 zap（结构化、高性能），每条日志带 trace ID（从 HTTP header 或 gRPC metadata 透传）
- 暴露 /metrics（用 prometheus/client_golang）和 /debug/pprof，便于排查性能瓶颈
基本上就这些。不复杂但容易忽略的是：proto 文件要早对齐、错误码要统一定义（gRPC 用 status.Code，HTTP 用标准 HTTP 状态码）、跨服务事务用 Saga 模式而非两阶段提交。Go 的简洁性和并发模型，让微服务落地比想象中轻量。
持多语言、流式传输、强类型契约。Go 生态对 gRPC 支持极好。