Golang框架如何拆分服务_Golang微服务改造指南-Golang-PHP中文网

真正卡住微服务落地的是初始化依赖、跨包调用和proto定义三处；需通过go list分析依赖图，确保模块具备独立生命周期、连接池与配置，用接口隔离领域边界，client封装下游调用并集成服务发现，proto按服务粒度拆分且严格版本兼容。

golang框架如何拆分服务_golang微服务改造指南

拆分服务不是起新 repo 或改 import 路径就能解决的事——真正卡住落地的，是初始化依赖、跨包调用和 proto 契约这三处。你跑通 go run cmd/userapi/main.go 不代表它已经是服务，得先验证它能不能独立启停、独立配 DB、不碰其他服务的 internal。

别看它叫 user 就急着建 user-service。先执行：go list -f '{{.Deps}}' ./cmd/main，画出依赖图：

如果 user 初始化强依赖 order.Repository 或共享同一个 *sql.DB 实例，那它现在只是模块，不是服务
能拆的前提：有自己完整的生命周期（启动/关闭 DB/Redis/第三方 SDK）、不共用连接池、配置项可独立覆盖
常见错误：在 user.Service 里直接调 order.GetByID() —— 这说明领域边界没划清，得先抽象出 order.OrderReader 接口

很多团队把所有 .proto 塞进一个 api 仓库，结果改个字段全链路得同步发版。这不是微服务，是 proto 单体：

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

.proto 必须由服务提供方定义，放在统一目录如 api/user/v1/user.proto，禁止散落在各服务 internal/ 下
禁止定义聚合接口，比如 rpc GetUserWithOrders(...) —— 这等于把组合逻辑强绑在契约上，下游一加字段你就得改 proto、发版、等客户端升级
版本管理写进包名，如 package userpbv2;，而不是靠 URL 路径 /api/v2/user（gRPC 不认这个）
字段变更必须向后兼容；否则旧客户端可能 panic 在 Unmarshal 阶段，错误信息只是 "proto: cannot parse invalid wire-format data"

http.Get("http://order-svc:8080/v1/order/123") 这种写法本地跑不通，上线扛不住节点故障，更没法做超时、重试、熔断：

所有下游调用必须封装成 client 接口，例如：type OrderClient interface { GetOrder(ctx context.Context, id string) (*Order, error) }
client 实现里才用 http.Client 或 gRPC stub；初始化交给 DI 容器（如 dig）或构造函数链，绝不在 handler 里 new
生产环境必须走服务发现：Consul + go-micro/registry/consul，或 DNS SRV 记录；开发环境用 localhost + 端口映射，别写死 host
硬编码地址会导致链路追踪 tag 串不起来，超时控制失效，重试策略无法注入

真正难的不是写代码，是让每个服务在编译期就“不认识”其他服务的实现细节——interface 抽象、client 封装、proto 契约先行，这三件事漏掉任何一环，拆出来的就是分布式单体。