ACID事务的边界局限：跨服务通信为何无法沿用ACID

在单体架构里，把用户信息写入CRM表和账单表可以放进同一个数据库事务，靠ACID（原子性、一致性、隔离性、持久性）保证：任何一步失败都能整体回滚，两个并发写入会被乐观锁或悲观锁强制隔离，一个成功另一个自动回滚失败重来——这种能力让业务逻辑可以把大量一致性复杂度直接甩给数据库事务层去处理，前提是所有数据都在同一个数据库、所有服务共用同一个数据库连接，而这只有单体架构才能满足。一旦CRM和账单变成两个独立服务、彼此靠远程通信访问，各自可能有自己的ACID事务，但这些事务无法联合成一个跨服务的整体：客户可能已经出现在CRM系统里，账单系统却还没创建对应记录，这违反了隔离性（外部线程或人已经能看到这个中间状态），一旦账单系统那边出问题，CRM系统里那条记录也没法回滚，只能留在那里。现代系统普遍面临这种局面，原因有几个：组件越来越分布式，即便存在XA两阶段提交这类分布式ACID事务技术，也普遍昂贵、复杂、脆弱，普通项目应该默认涉及远程通信时ACID事务不可行；不同类型的资源（多个物理数据库实例、消息系统等中间件）本来就通常无法加入同一个ACID事务；业务活动因为要等待异步响应或人工操作而变得长期运行，数据库ACID事务不能长时间保持打开，否则会产生死锁或超时；活动本身也可能复杂到无法塞进一个巨大事务里处理。综合起来，现代架构的工作正在越来越多地被拆成多个彼此独立的任务，不再合并进单个ACID事务，这就需要一种全新的方式来处理业务层面的一致性，而不只是依赖底层数据库能力。