企业官网建设流程全解析

很多团队拆微服务，拆完发现调用链更长了，故障更多了，发布反而更慢了。问题不在微服务本身，而在边界画错了。下面这4条边界线，是拆分时最容易踩坑的地方。

一、业务能力边界：不是按技术分层，也不是按数据库表

最常见的错误是按技术分层拆：Controller一个服务、Service一个服务、DAO一个服务。这等于把单体应用的内部调用变成了网络调用，性能暴跌，还引入了分布式事务。另一种错误是按数据库表拆：用户表一个服务、订单表一个服务、商品表一个服务。结果一个下单操作要跨三个服务，每个服务只做CRUD，业务逻辑碎了一地。

正确的边界是业务能力。比如电商系统，应该按“订单管理”“库存管理”“用户管理”“支付管理”来拆。每个服务封装一个完整的业务能力，对外提供粗粒度接口。判断标准很简单：如果两个功能总是一起变更、一起发布，它们就不该被拆开。

二、数据所有权边界：每个服务独占数据库，不能共享表

很多团队拆了服务，但数据库还是同一个，服务A直接查服务B的表。这等于没拆——表结构一变，两个服务一起挂。更隐蔽的是“共享库但不同表”，看似隔离，实际上外键约束、事务边界、连接池竞争依然存在。

正确的做法是每个服务独占一个数据库，只能通过API访问别人的数据。这意味着要放弃跨服务的JOIN，改用接口组合或数据冗余。比如订单服务需要用户名，可以在下单时把用户名冗余到订单表，而不是每次去查用户服务。数据冗余带来一致性问题，但这是分布式系统必须接受的权衡。

三、团队组织边界：康威定律不是让你按现有团队硬拆

康威定律说“系统架构反映组织沟通结构”。很多管理者反过来用：我们有三个组，那就拆三个服务。结果一个组维护五个服务，或者一个服务横跨三个组，沟通成本爆炸。

正确的边界是团队自治。一个服务应该由一个团队端到端负责，包括开发、测试、部署、运维。服务边界和团队边界要对齐，但前提是团队划分本身合理。如果两个组经常需要同步发布，说明它们之间的服务边界画错了。反过来，如果一个服务需要三个组协调才能改一行代码，这个服务就该重新划分。亚马逊的“两个披萨团队”原则值得参考：一个服务小到用一个披萨就能喂饱团队。

四、事务与一致性边界：强一致性事务内不能拆，最终一致性边界外才拆

这是最容易被忽视的一条。很多人把需要强一致性的操作拆到不同服务，然后用分布式事务（如Seata）硬撑。结果系统复杂度飙升，性能下降，故障率反而更高。

正确的边界是：强一致性事务必须在一个服务内完成。比如“扣库存”和“创建订单”如果必须同时成功或失败，它们就应该在同一个服务里。如果业务允许最终一致，比如“下单后发短信通知”，那就可以拆出去，用消息队列异步处理。判断标准：问业务方，这个操作失败后能不能容忍短暂不一致？不能，就别拆。

总结

微服务拆分的本质是划定边界，而不是追求“小”。边界画对了，服务再大也是微服务；边界画错了，服务再小也是分布式单体。四条边界线记住：按业务能力拆，不按技术层；数据独占，不共享表；团队自治，不按现有组硬套；强事务内聚，最终一致才拆。最后提醒一句：边界是演进而来的，不是一开始就设计完美的。先粗后细，让边界在业务压力下自然浮现，比拍脑袋拆一堆服务靠谱得多。