微服务拆分应以解决协作卡点、发布风险与技术栈收敛为目标，必须按限界上下文而非模块名划分边界，明确数据主权，封装client接口并交由di管理，严守grpc聚合根原则，数据库共实例但schema隔离。
拆微服务不是为了“看起来像微服务”，而是为了解决单体里团队协作卡点、发布风险高、技术栈无法收敛这些真实问题。如果当前单体跑得稳、改得快、扩得灵，别急着拆。
按限界上下文拆，而不是按模块名或表名拆
很多团队一上来就建 user-service、order-service，结果半年后发现登录要查用户基本信息+实名状态+风控等级+消息推送开关——四个字段来自四个不同业务规则，全堆在一个服务里，接口越加越多，数据库 schema 被迫开放。
真正该做的，是画出限界上下文（Bounded Context）：
- 谁对“用户”这个概念有数据主权？是注册流程决定 ID 生成规则，还是会员系统决定等级升降逻辑？
- 一个需求变更是否只改一个服务？比如“增加手机号一键登录”要不要同时动
auth-service、user-service、sms-gateway？如果要，边界就错了 - 优惠券在发券、核销、风控中语义完全不同，强行塞进一个
coupon-service，必然妥协接口、共享数据库、绕过领域规则
服务间调用必须封装 client 接口并交由 DI 管理
常见错误现象：http.HandleFunc("/pay", func(w http.ResponseWriter, r *http.Request) { resp, _ := http.Get("http://order-svc:8080/v1/order/123") })——这种写法会让服务失去弹性，无法做重试、超时、熔断，且本地开发时根本没法联调。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操建议：
- 所有下游调用必须抽象为接口，例如
type OrderClient interface { GetOrder(ctx context.Context, id string) (*Order, error) } - 实现里才用
http.Client或 gRPC stub，不要在 handler 层硬编码地址 - client 初始化交给 DI 容器（如
dig或手写构造函数），测试时可轻松注入 mock 实现 - 生产环境用服务发现（如 Consul +
go-micro/registry/consul）或 DNS SRV 记录，避免把order-svc:8080写死在代码或 config.json 里
gRPC 和 HTTP 共存时，proto 文件别变成新的单点故障
很多团队用 gRPC 拆服务后，把所有 .proto 放进一个 api/ 仓库，各服务都 go get 它——结果改一个字段，全链路得同步发版，反而比单体还脆弱。
关键控制点：
- 每个服务只定义和自己强相关的 proto message，不暴露无关字段
- 跨服务调用的 request/response 类型应由被调用方定义，调用方只依赖其 client 接口，而非原始 proto
- 版本升级时，用
google.api.field_behavior标注必选/可选字段，避免破坏性变更 - proto 编译产物（如
pb.go）不应直接 commit 到业务服务 repo，而应通过 CI 自动生成或 vendor 引入
最容易被忽略的是：数据主权归属没厘清之前，任何物理拆分都是徒增复杂度。订单和订单明细属于同一限界上下文，不应拆分；订单和用户属于不同上下文，可以拆分。这点一旦错判，后续所有治理手段都会失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
