从单体到微服务的血泪史
一次真实的架构迁移经历，踩了哪些坑，得到了什么教训。
我们花了一年半时间把一个 Rails 单体拆成微服务，结果发现有些坑是不踩不知道深的。
为什么要拆
那时候的理由很充分：部署速度慢、团队扩张后代码耦合严重、某个模块崩溃会拖垮整个系统。这些问题都是真实的，微服务看起来是正确答案。
第一个坑：边界划分
我们按照业务模块拆分，结果发现”业务模块”在数据层其实是强耦合的。用户服务、订单服务、商品服务，听起来很清晰，但一个查询可能需要跨三个服务的数据。
分布式 join 的代价是巨大的，我们第一版基本上是把数据库层的 join 翻译成了跨服务的 HTTP 调用，性能惨不忍睹。
第二个坑：分布式事务
单体里一个 ActiveRecord.transaction 搞定的事情，在微服务里变成了 Saga 模式、补偿事务、幂等性设计……复杂度指数级上升。
我们有个支付流程，花了三个月才真正做到数据一致性。单体里两周能做完。
第三个坑：运维复杂度爆炸
单体：一个进程，一个日志文件，一个部署单元。出问题了看日志很清楚。
微服务：十几个服务，链路追踪、集中式日志、服务发现、健康检查……没有专职的平台团队，这些东西会把你压垮。
教训
微服务不是架构问题的银弹，它是组织问题的工程化解法。如果你的团队规模和业务复杂度还撑不起这个方案，单体不丢人。
康威定律没有例外。