重新思考业务流程与用户体验：火车票同步预订案例

架构已经在向分布式、异步、最终一致的方向演进，但作者观察到业务部门往往还没理解这背后带来的机会——为了不改变用户熟悉的体验，团队常常把长期运行的能力硬塞进一个同步facade里，[[同步facade背后的异步通信三种响应接收方式与优雅降级模式]]描述的技术手段固然可行，但作者真正想挑战的是”业务部门坚持要同步体验”这个前提本身。以订火车票为例：选路线、选座、选票种票价、填个人信息和支付信息、点结账、等一个转圈动画——这种全同步体验在现代分布式架构里其实很难真正实现（呼应第9章的一致性讨论）。业务方通常给出两个理由坚持同步：一是”预订出问题必须立刻告诉用户，只有同步返回才能做到”，二是”预订成功后要立刻生成PDF车票供打印”，作者都不认同。针对第一点：完全可以在流程的中间环节暂停并异步通知用户——给一个漂亮的状态页面代替干等的转圈动画，用一个唯一的长链接让用户随时能离开、之后回来还能看到最新进展，有需要用户关注的事情就发邮件或应用内通知；而且即便你坚持提供同步体验，这些问题依然绕不开——比如给用户占了一个座位、后台服务紧接着就崩了，你照样得给用户提供重新预订的方式，或者至少给这个占座加个超时；作者还举了一个现实中人人都遇到过的例子——预订航班时浏览器崩溃，第一次会话技术上并没有真正结束，但用户显然不可能指望自己选的座位还在，这说明”异步架构+同步用户体验”这种混合状态本身就已经在制造奇怪的现象，倒不如正面拥抱最终一致性，给客户一个明确的时间窗口去完成预订。针对第二点：现在还有多少人真的要打印车票？智能手机和应用早就改变了用户体验，为了保住这个边缘需求而坚持全同步、让整个预订流程”要么全成要么全崩”，用户显然不会更喜欢这种设计。放弃”必须同步”的执念还有一个附加好处：系统不用一直在同步和异步之间来回切换，实现会简单得多——真正需要的只是让业务人员从头重新思考客户体验，作者引用Eliyahu Goldratt的话总结这种常见失败：”你部署一项令人惊叹的技术，但由于没有改变工作方式，所以实际上并没有减少什么限制”。