微服务拆分需依据三个硬指标：数据库表是否共享核心业务实体、模块发布节奏差异是否超3:1、同一文件是否被不同团队高频修改引发合并冲突；拆分时须避免HTTP地址硬编码、proto集中管理及同步异步混用。
微服务不是一拆就灵，Go项目从单体演进到分布式，真正卡住进度的从来不是代码量或框架选型，而是数据边界没划清、调用链没解耦、部署单元没对齐——这些地方一错，后续所有治理能力都建在流沙上。
怎么判断该不该拆：看三个硬指标
别被“高并发”“大团队”这类模糊说法带偏。实际决策只依赖三件事：
- 数据库表是否共享核心业务实体。比如
order和order_item必须同库同服务；但user表和order表之间如果只有外键引用，且无联合事务，就可以物理隔离 - 两个模块的发布节奏是否差异超过 3:1。例如促销规则每周上线 5 次，而用户认证半年才改一次，这就是强拆信号
- Git 提交记录里，同一文件被不同团队反复修改且合并冲突频发。这说明组织边界已经压过了代码边界，康威定律正在生效
拆分时最容易踩的坑：HTTP 调用写死地址
常见错误现象：http.Get("http://order-service:8080/v1/order/123") 直接出现在 handler 里。后果是本地联调失败、无法注入熔断逻辑、测试只能打桩 HTTP client。
正确做法：
立即学习“go语言免费学习笔记（深入）”；
- 定义接口，如
type OrderClient interface { GetOrder(ctx context.Context, id string) (*Order, error) } - 实现类里用
http.Client或grpc.ClientConn，但绝不暴露具体地址 - 初始化交给 DI 容器（比如
dig），生产环境通过 Consul 或 DNS SRV 解析服务名 - 配置项里只存服务名（
order-service），不存 host:port
proto 文件管理：别让 API 定义变成新单点故障
很多团队把所有 .proto 放进独立仓库，各服务 go get 同一版本——结果改个字段就得全链路发版，比单体还脆弱。
实操建议：
- 每个服务只维护自己暴露的 proto，比如
user-service只管user.proto，order-service只管order.proto - 跨服务调用时，下游服务生成自己的 stub（
order_client.pb.go），不复用上游的完整 proto 仓库 - 如果必须共享类型（如
common.Status），抽成api/common/子目录，但禁止跨领域引用业务消息体
服务间通信选型：同步还是异步，看一致性要求
不是“gRPC 就比 HTTP 好”，也不是“消息队列一定更可靠”。关键看业务语义：
- 订单创建时校验库存，必须等返回结果才能继续——用
gRPC同步调用，配合超时与重试 - 支付成功后更新用户积分，允许延迟几秒——走
Kafka或RabbitMQ，用事件驱动解耦 - 避免混合使用：同一个业务流程里既用 gRPC 又发 MQ，会把事务边界搞模糊，调试时根本分不清哪一步失败了
真正的复杂点不在代码怎么写，而在每次拆分前，你是否愿意花半天时间画出当前 main.go 的初始化依赖图、标出所有跨包调用路径、确认每张表的 owner 是谁——这些事没人替你做，也绕不过去。
