拆分服务应基于业务演进节奏与变更影响范围，以限界上下文识别真正独立发布、扩缩容且数据自治的边界；错误拆分将导致“分布式单体”，运维与排查成本激增。

拆分服务不是把单体代码按文件夹切开，而是根据业务演进节奏和变更影响范围，划出真正能独立发布、独立扩缩容、数据不共享的边界——拆得对，一个服务改了，其他九个照常运行；拆错了，就是“分布式单体”，运维成本翻倍，问题排查更难。

用限界上下文识别服务边界，别信“用户/订单/支付”这种默认划分

很多团队一上来就建 user-service、order-service、payment-service，结果发现“创建订单”要同步调用用户校验、库存扣减、优惠券核销、风控拦截……每个环节 SLA 不同、失败策略不同、数据库事务要求不同，硬塞进一个服务里，只会让逻辑越来越重、部署越来越卡。

• 真正该拆的是“能力单元”：比如 coupon-issuance（优惠券发放）走审批流+库存锁，而 coupon-redemption（核销）走实时风控+交易上下文，两者连数据库 schema 都不一致，就必须拆成两个服务
• 画出核心流程图，标出每个环节的负责人、超时容忍度、是否允许异步、是否需要强一致性——凡是标着“可最终一致”“部署节奏不同”“失败后走补偿”的环节，就是潜在拆分点
• DDD 不是教条，而是工具：限界上下文不是名词堆砌，而是问一句——“这个功能改了，会影响其他几个服务的测试、发布、监控配置？”答案是“0”，才算边界清晰

proto 契约先行，禁止跨服务直连数据库或共用 DAO 库

服务间通信必须通过明确契约，而不是靠“我们都知道 user 表结构”这种默契。Go 没有接口继承，但 protobuf + gRPC 正好补上这一环：契约即代码，生成即约束。

• .proto 文件必须由服务提供方定义，放在统一目录（如 api/order/v1/order.proto），不能散落在各服务 internal 下
• 禁止在 order-service 里直接 import user-service/internal/repository 或拼 SQL 查 user 表——这等于把耦合写死在编译期
• 数据自治不是口号：每个服务的 go.mod 里不该出现其他服务的数据库驱动依赖；repository 层只对接本服务私有 DB，对外只暴露 GetUserByID(ctx, id) 这类能力接口
• 示例中常见错误：

  conn, err := grpc.Dial("user-service:50051", grpc.WithInsecure()) // ✅ OK  
  // ❌ 错误：db, _ := sql.Open("mysql", "user:pass@tcp(user-db:3306)/user")

内部模块按 handler/service/repository 分层，但用 internal 封装实现细节

单个微服务内部不是“扁平化”，而是要有清晰职责分层，同时防止外部服务越权调用内部逻辑——Go 的 internal 目录是语言级封装机制，不用白不用。

MergeIQ: Automatically Score & Prioritise PR Complexity for GitLab and GitHub

使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...

下载

立即学习“go语言免费学习笔记（深入）”；

• 推荐结构：/cmd/order-service/main.go 入口 → /internal/order/handler.go（只做参数解析、响应包装）→ /internal/order/service.go（核心逻辑，协调多个 repository 或 client）→ /internal/order/repository.go（仅封装本服务 DB 操作）
• handler 层绝不处理业务规则，比如“库存不足是否允许下单”这种判断必须下沉到 service；repository 层绝不返回 *sql.Rows 或原始 error，只返回领域模型和自定义错误类型
• 所有跨层调用通过 interface 定义，例如：

  type UserRepository interface {  
      GetUserByID(ctx context.Context, id string) (*User, error)  
  }  
  // 实现可替换：mock / mysql / redis，不影响 service 层

• 避免把 pkg/common 做成“大杂烩”：日志、错误码、中间件可以复用，但“用户校验逻辑”“订单状态机”这类业务敏感代码，必须留在各自服务内

初期别追求一步到位，用“单体先行 + 能力抽离”降低风险

从零开始就建十个服务，90% 会返工。更现实的做法是：先在一个 monorepo 里用清晰目录隔离模块，等某个能力出现明显变更压力（比如优惠券发放上线频率远高于核销），再把它抽成独立服务。

• 先在 /internal/coupon/issuance/ 和 /internal/coupon/redemption/ 里用 interface 隔离，跑通本地集成测试
• 再把 issuance 提炼为独立 module，加 go.mod，暴露 IssuanceService 接口，用 gRPC 对接
• 最后通过 replace github.com/your-org/monorepo => ./services/coupon-issuance 在开发阶段联调，上线前才切真实 endpoint
• 关键信号不是“代码量多”，而是“每次改它都要拉上三个团队一起回归测试”——这时候，就是该拆的时候了

最容易被忽略的一点：服务拆分不是架构师闭门画图的结果，而是从最近三次线上故障的根因分析里长出来的——哪个环节的修改引发了最多连锁反应，那个环节的边界，大概率还没划准。