Golang微服务核心是解耦而非接口实现，需按独立演进的业务能力拆分（如“优惠券发放”与“核销”分离），通过proto契约、依赖倒置、数据自治与事件驱动保障模块间零牵扯。
用 Golang 构建分布式微服务，核心不是“怎么写接口”，而是“怎么让模块之间不牵扯”。拆分模块和解耦依赖，本质是控制变化的传播范围——一个服务改了，别让十个服务跟着重启、重测、重发布。
按业务能力而非技术层拆分服务
别按“用户服务”“订单服务”“支付服务”这种粗粒度切，也别按“API 层”“逻辑层”“DAO 层”纵向切。要识别出真正独立演进的业务能力单元。比如“优惠券发放”和“优惠券核销”，看似都属营销域，但发放走审批流、依赖库存系统；核销走实时风控、依赖交易上下文——它们的变更节奏、数据一致性要求、失败容忍度完全不同，就该拆成两个独立服务。
建议做法：
- 画出核心业务流程图，标出每个环节的负责人、SLA 要求、外部依赖点
- 对频繁一起修改、共享同一份数据库表、必须强一致的逻辑，保留在同一服务内
- 对仅通过事件或异步消息交互、允许最终一致、部署节奏不同的功能，果断拆出新服务
用接口契约 + gRPC/Protobuf 明确边界
Go 没有接口继承机制，但恰恰适合定义轻量、稳定、面向能力的接口。不要暴露 struct 或内部 error 类型，所有跨服务调用必须通过 protobuf 定义的 .proto 文件生成的 client/server stub。
立即学习“go语言免费学习笔记（深入）”；
关键细节：
- 每个服务只维护自己的 proto 目录，不共用一个 mega-proto 仓库
- message 字段全部加 optional（proto3 默认），新增字段不破坏旧客户端
- 错误统一用 status.Code（如 codes.NotFound, codes.InvalidArgument），不传自定义 error 字符串
- 服务启动时校验 proto 版本兼容性（可用 protoc-gen-validate 或自定义插件）
依赖倒置：用接口抽象替代具体实现注入
服务 A 调用服务 B，A 不该直接 new B 的 client，更不该 import B 的 internal 包。正确方式是：A 定义它需要的能力接口（如 PaymentProcessor），B 提供符合该接口的实现（如 grpcPaymentProcessor），由启动时的 DI 容器（如 wire 或 fx）注入。
这样做的好处：
- 本地测试可注入 mock 实现，不依赖网络或真实服务
- B 升级 gRPC 到 HTTP/3 或换用消息队列，只要接口不变，A 完全无感
- 多个 B 的实现可并存（如灰度环境用 mockPayment，生产用 grpcPayment）
数据自治：每个服务独占数据库 + 事件驱动同步
禁止跨服务直连对方数据库，也别用“公共库”封装 DAO。每个微服务拥有自己的数据库实例（哪怕物理同机），表结构不对外暴露。服务间数据同步靠事件：
