事件链实现业务流程的代价：变更牵连多组件与分布式版本管理

事件链是一系列真正实现某个业务流程逻辑的事件订阅，彼此并非相互独立——例如支付服务监听结算服务发出的下单事件、库存服务监听支付服务发出的收到付款事件，端到端订单履约流程就从这一连串订阅中”涌现”出来。乍看这提高了自主权，但代价很明确：在事件链中，任务需要按特定顺序执行（如必须先支付成功才能发货），可整个系统里没有任何地方能让人理解这个顺序，更别说控制它；而组织里通常总有人要对端到端订单履约的SLA负责，从这个人的视角看，”业务流程靠涌现实现”完全不可接受，因为它依赖事件恰好在正确的时间被正确的服务接收。一旦需要改变事件的执行顺序（比如业务部门想在支付成功前就先从仓库提货，以确认真的有库存），这种变更没法只改一个服务：支付服务要从监听下单事件改成监听提货成功事件，库存服务要改成收到下单事件后立即提货，发货服务要改成监听支付成功而非提货成功——这需要三个微服务团队坐下来协调部署时间表，达成集体部署或分阶段发版的共识，”这更像单体架构而不是微服务”。除此之外还有一个分布式版本管理问题：系统里流转的每个订单都要清楚自己是在哪个版本的事件序列上启动的，如果订单是长期运行、要停留几小时到几天的，部署变更时系统里必然同时存在跑在新旧两种序列上的订单。很多初创公司早期用少量微服务和事件总线能快速新增功能，但公司成长到需要改变已有功能时，往往发现根本弄不清这些事件在哪里被消费、变更会引发什么连锁反应——事件能让加功能变简单，代价是改事件链会变得极难，这个取舍应该有意识地做，并持续追踪由此累积的技术债务。