Go 微服务项目复盘一次架构重构的决策路径与经验一、单体太慢拆成微服务就好了——拆完后发现更慢了这是一个经典的反讽团队把单体应用拆成 12 个微服务后一个简单的用户信息查询从 50ms 变成了 800ms。不是因为微服务本身有问题而是拆分的粒度和通信模式没有设计好。用户信息查询需要调 4 个服务用户服务 → 权限服务 → 组织架构服务 → 偏好设置服务每个调用是 RPC 链式串行中间任何一个超时就拖累全局。这个项目从单体到微服务再到合理的服务拆分经历了一年三次重大重构。以下是决策路径和关键教训。二、三次重构的演进过程第一次切分按数据库表来——每张表一个微服务。用户表变用户服务订单表变订单服务。耦合最紧密的用户和订单被拆开每次查订单都要关联用户信息跨服务调用从 0 变成了 N。第二次切分更细——订单拆成订单创建、订单查询、订单状态变更三个服务。服务间通讯量指数级增长网络延迟从微服务内部的 0.1ms 变成了跨服务的 5-10ms × N。第三次按业务领域聚合——用户相关的 3 个服务合并为一个用户域交易相关的合并为交易域。跨域调用通过 BFF 层聚合域内调用直接走本地方法零网络延迟。三、关键决策点的复盘决策一什么时候拆不是系统变慢了就拆。判断标准某个模块是否独立部署、独立扩缩容、由独立团队维护。如果三个问题的答案都是是才值得拆。如果只是因为代码写了太多行就想拆那应该先做代码分层而不是微服务化。决策二怎么定服务粒度不是一个服务只做一件事那是函数的粒度。合理的粒度是一个服务管理一个聚合根Aggregate Root。订单聚合根包括订单头、订单行、收货地址——它们总是一起被访问和修改的应该在一个服务里。订单行被单独拆出去只会制造不必要的跨服务调用。决策三数据一致性怎么保证微服务拆分后订单服务和库存服务的数据分属两个数据库。创建订单时扣减库存不能用传统数据库事务。我们选了 Saga 模式 消息队列做最终一致性——订单创建后发消息给库存服务扣库存扣失败则发补偿消息回滚订单状态。核心教训补偿事务要设计好幂等性——库存扣了又回滚、再扣不能重复扣两次。决策四服务间通信协议选什么起初用 gRPC性能好、类型安全但很快遇到了问题前端调用微服务时要做 HTTP → gRPC 转换需要额外的 Gateway 层。后来统一改为 HTTP JSON牺牲了 10% 的性能换来了零配置的互操作性和更简单的调试体验。在初创团队的场景下这 10% 的性能差异远不如可维护性重要。四、经验提炼不要为了微服务而微服务。单体应用有很多成熟的优化手段读写分离、连接池、缓存、索引优化这些都没做就直接上微服务是用分布式复杂度解决单机性能问题。我们第一次拆微服务时最大的错误就是没有先做单体的极限优化。后来复盘发现单体应用的 p99 延迟是 200ms其中 85% 的时间花在数据库查询上。加了索引、读写分离和 Redis 缓存后p99 降到了 80ms。这才有了真正的微服务拆分的基线——知道自己需要优化的不是微服务架构而是具体的性能瓶颈。BFF 层不是可选项。没有 BFF 层Backend For Frontend的微服务架构前端需要知道 12 个服务的地址和协议。BFF 层做服务聚合、协议转换、降级兜底是微服务架构中最重要的组件之一。我们团队是在被前端同事追着骂了一周后才意识到这个问题的——每次后端服务改端口或切域名前端就要跟着改配置、改环境变量、重新发版。引入 BFF 层后前端只需要知道一个地址BFF 负责路由和聚合。更重要的是BFF 可以做到断路器的效果当某个微服务挂掉时BFF 可以返回缓存数据或降级响应而不是让用户看到 500 错误。Saga 比 2PC 更务实。分布式事务两阶段提交 2PC在理论上是完美的在工程上是灾难——锁定时间长、协调者单点故障、性能极差。Saga 消息队列的最终一致性足够覆盖 95% 的业务场景。我们内部定了一条规则Saga 的补偿事务必须支持幂等重放任何中间状态都要能在数据库中被追溯。举个例子订单创建后发消息扣库存扣库存失败时发补偿消息回滚订单。但如果补偿消息因为网络问题发了两遍订单会被回滚两次吗我们用 订单 ID 操作类型 版本号 做了幂等键确保同一个回滚操作只执行一次。五、总结微服务重构项目最值钱的经验是什么时候不该拆。判断标准不是技术洁癖这个类和那个类耦合太紧而是业务需求这个模块需要独立伸缩吗由独立团队维护吗可以独立发布吗。三次重构后沉淀的架构原则按业务领域聚合服务不是按数据表用 BFF 层封装服务间的调用复杂度选 HTTPJSON 而不是 gRPC除非高性能是核心需求用 Saga 替代 2PC 处理跨服务数据一致性。最重要的是——如果单体还没优化到瓶颈不要为了架构先进去上微服务。