选择将其他服务通过事件消息发出的数据持久化保存或者缓存起来。比如，在fee服务收到OrderCreated事件消息后，可以选择将这个订单的详细数据保存下来，而非仅仅保存关联ID。这样，fee服务就可以处理诸如“这个订单的金额是多少”这样的查询请求，而不再需要另外调用order服务来获取这个数据。
使用事件消息来共享状态数据并复制到不同的服务中，这种技术非常有用，但是也存在一些风险：1) 维护数据的多个副本增加了整个应用和服务的复杂度（很可能还包括整体的存储成本）；2) 修改事件消息的格式会变得相当棘手难以处理，因为服务和事件消息的内容耦合得越来越紧；3) 缓存失效是众所周知的难题。
将标准化数据保存到多个位置中，然后通过异步事件来更新，但是由于事件会存在延迟、失败或者重复发送的问题，开发者不得不处理最终一致性问题以及获取到的数据副本可能已经过期的问题。
是否能够接收数据有时候已经过期是由特定功能的业务含义决定的。但这是一个两难的选择。CAP理论告诉我们，我们不可能两全其美：我们需要在可用性（成功返回一个结果，但不保证数据是最新的）和一致性（返回当前最新的状态，或者出错）两者之间进行选择。
数据一致性保证会导致系统间的协作越来越多（如分布式锁），而这会阻碍事务的执行速度。相比之下，一个系统如果想要最大限度地提升可用性基本上都是靠补偿操作和重试。
如果在开发系统时，将可用性放在第一位，那么开发者在面对问题时就需要避免那种本能的、面向一致性的解决方案。即便某些系统看起来应该将一致性作为第一优先级，但是为了最大限度地提高使用的成功率，也往往会优先选择可用性作为折中的办法。
自动柜员机（ATM）就是一个很好的例子——将可用性放在第一优先级能够增加银行的收入。如果一台ATM机或者更大范围的ATM网络不能连接银行后台，我们仍旧可以在ATM机器上取款，但是会有金额限制，以确保控制透支的风险。如果某位客户提款出现透支问题，银行会另外扣除一定的手续费。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论