微服务拆分应以解决单体架构中团队协作卡点、发布风险高、技术栈无法收敛等真实问题为目标，核心依据是限界上下文而非表或模块名，需确保服务边界清晰、数据主权明确、接口职责单一、数据库隔离、通信契约严谨，并接受最终一致性，持续演进而非一蹴而就。
拆分微服务不是为了“看起来像微服务”，而是为了解决单体里团队协作卡点、发布风险高、技术栈无法收敛等真实问题。如果当前单体跑得稳、改得快、扩得灵，别急着拆。
按限界上下文拆，而不是按表或模块名拆
很多团队一上来就建 user-service、order-service，结果半年后发现：登录要查用户基本信息+实名状态+风控等级+消息推送开关——四个字段来自四个不同业务规则，全堆在一个服务里，接口越加越多，数据库 schema 被迫开放，最终变成“分布式单体”。
真正该做的，是画出限界上下文（Bounded Context）：
- 谁对“用户”这个概念有数据主权？是注册流程决定 ID 生成规则，还是会员系统决定等级升降逻辑？
- 一个需求变更是否只改一个服务？比如“增加手机号一键登录”要不要同时动
auth-service、user-service、sms-gateway？如果要，边界就错了 - 优惠券在发券、核销、风控中语义完全不同，强行塞进一个
coupon-service，必然妥协接口、共享数据库、绕过领域规则
初期可共用 PostgreSQL 实例，但必须用不同 schema 或 database，禁止跨 schema JOIN；否则运维上线前会直接叫停。
立即学习“go语言免费学习笔记（深入）”；
gRPC 接口定义不写清楚，上线第一周就得返工
用 protoc 生成代码很爽，但如果你的 .proto 文件里写着 rpc GetUserWithOrders(GetUserRequest) returns (GetUserResponse)，等于把聚合逻辑强绑在服务契约上。下游一要加收货地址字段，你就得改 .proto、发版、等所有客户端升级——这不是微服务，是 RPC 单体。
正确做法：
- 接口只暴露“本上下文能且只应提供的能力”：
GetUser返回User，别带repeated Order；订单归属由调用方自己查order-service - 字段增删必须向后兼容：
reserved 3;标记废弃字段，并在注释写明// deprecated since 2026-01, remove in v2.1 - 新增字段必须设默认零值：
int32 version = 4 [json_name = "version"];，不能依赖客户端传值，否则旧 client 一调就 panic 报"proto: cannot parse invalid wire-format data" - 版本写进包名，别用 URL 路径：
package userpbv2;，而不是靠/api/v2/user——gRPC 根本不认路径
HTTP/JSON 不是退而求其次，而是中小团队最可控的选择
别被“gRPC 性能高”带节奏。你真测过吗？在内网千兆网络下，gRPC 比 JSON 快不到 1ms，但调试成本翻倍：curl 不好使、浏览器打不开、前端联调要装插件、错误堆栈藏在二进制流里……很多团队卡在 context deadline exceeded 却查不出是哪一层超时。
推荐策略：
- 对外 API（给 App、Web、第三方）统一走 HTTP/JSON，用
Gin或chi做路由和中间件 - 内部服务间通信，优先评估是否真需要 gRPC：如果只是简单读写、QPS 不高、团队没 protobuf 维护经验，直接用 HTTP +
net/http更轻量 - 若坚持用 gRPC，务必配好
grpc-go的拦截器：日志、metric、timeout、重试，否则线上出问题连 trace 都串不起来
拆分后第一个踩坑点：数据库事务与一致性
单体里一个事务搞定用户扣款+订单创建+库存扣减，拆完之后这三件事分布在三个服务，没法用 ACID 保证。别幻想“用 Saga 模式就能完美替代”，Saga 写起来复杂、补偿难测、失败路径多，小团队容易掉进状态机黑洞。
务实做法：
- 先接受“最终一致性”，用事件驱动：订单服务保存成功后发
order.created事件，库存服务监听并异步扣减 - 关键路径加幂等：每个消费方对事件 ID 做去重，避免重复扣库存
- 不要让一个服务“主动调另一个服务的写接口”来模拟事务，那只是把单体事务搬到了网络上，延迟+失败率双升
- 初期可用本地消息表 + 定时任务兜底，比直接上 Kafka + Exactly-Once 更易落地
最常被忽略的一点：拆分不是一次性动作，而是持续演进的过程。服务边界会随业务变化而漂移，今天合理的限界上下文，半年后可能因新需求而需要合并或再拆。留出重构余地，比追求“一步到位”重要得多。
