异步事件能够帮助我们解除服务之间的耦合和提高系统整体的可用性，但是这也促使服务的开发者开始思考最终一致性(eventual consistency)。在采用最终一致性方案的系统中，开发者可以设计从多个独立的本地事务生成的复合型结果，这就需要为下层的各个资源明确设计各种暂时的状态。从埃里克·布鲁尔（Eric Brewer）的CAP理论的角度看，这种设计方案将底层数据的可用性放在第一位。
备注：CAP包括一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)。
订单出售如果以同步方案实现，order服务负责编配其他服务的行为，调用一系列的功能，最终订单被发布到市场上。如果任何一个步骤出现故障，order服务就负责启动其他服务的回滚操作，比如退回手续费。
在这种方案中，order服务承担了大量重要的职责：它知道需要调用哪些服务以及调用这些服务的顺序；在下游服务出错或者由于不符合业务规则而使下游服务不能正常处理时，它需要知道自己所要做的工作。
这种交互方式易于分析和推理，因为整个调用图是有逻辑性和顺序性的。但是，上述这些职责会导致order服务与其他服务会紧密耦合在一起，这会降低服务的独立性和增大未来修改的难度。
订单出售如果以异步方案实现，使用事件消息来重新设计。每个服务可以订阅它所感兴趣的事件消息，以确定何时必须执行工作。
（1）当用户通过界面发起出售请求时，应用发布一个OrderRequested事件。
（2）order服务接收这个事件后进行处理，然后向事件队列发出一个OrderCreated事件。
（3）transaction和fee服务都会接收到这个事件通知，这两个服务会执行它们相应的操作，然后在执行完成以后分别发出一个通知事件。
（4）market服务等待两个通知事件：收费确认事件和股票预定成功事件。一旦接收到这两个事件，market服务就可以向股票交易市场提交订单了。这步操作完成后，market服务就会向事件队列发送一个最终的事件消息。
事件使得开发者可以用一种乐观的方式来实现高可用。比如，即便fee服务出现故障，order服务仍旧能够创建订单。当fee服务恢复后，它可以继续处理积压的事件。我们可以将这个方法扩展到回滚的场景中：如果由于金额不足导致fee服务收费失败，fee服务可以发送一个ChargeFailed事件，然后其他服务就可以消费该事件来取消下单操作。
这种方式称为编排。每个服务可以在不了解整个流程结果的情况下响应各种事件，独立执行各种操作。这些服务就如同舞蹈演员一般：他们知道每一段音乐的舞步和要做的动作，不需要有人显式地请求或者命令他们，就会按照音乐的变化给出相应的反应。相应地，这种设计方式解除了服务之间的耦合，提升了各个服务的独立性，并且简化了独立部署变更的复杂度。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论