同步facade背后的异步通信：三种响应接收方式与优雅降级模式

有些客户端（尤其是前端客户端）必须拿到同步API，即使系统内部本质上是异步或长期运行的流程——这时的解法是搭一个同步facade，对外暴露同步REST等接口，内部由这个facade负责阻塞等待异步调用完成。接收异步响应有三种方式：订阅发送响应的消息通道、提供一个回调API、或定期轮询结果是否可用——三者各有取舍，具体选哪个取决于架构现状；它们的共同点是必须处理超时问题，因为不可能无限期阻塞等待，一定要考虑”限定时间内没有响应该怎么办”。作者观察到一种很常见、也很实用的设计模式：一切正常时走同步返回，出现错误时优雅降级到异步处理——正是[[同步调用的坏味道登机牌案例说明故障应留在服务本地]]中值机案例的正解：值机服务只有在一切顺利时才同步返回登机牌（HTTP 200，”一切正常，这是结果”），一旦出现故障导致无法立即出结果，就返回HTTP 202（”我知道了，稍后回复你”），随后通过邮件把登机牌异步送达。这种设计确实会影响用户体验——用户不能立刻拿到登机牌，但这未必是坏事：让用户稍后顺利收到登机牌，通常比让他们当场面对一个错误信息、还要自己想办法处理要好得多。