若没有最终一致性，分布式服务就不能存在。

要解决这个问题，我们有三种模式。

实际例子如下：

我们假设你有两个服务：订单服务和发票服务。

当客户下达订单时，你需要生成相应的发票。

解决方案有三种可能性：

保存订单之后，然后在后台更新或创建相应的发票。

计划任务会定期检查新的或已更改的订单，并创建或更新相应的发票。

这种方法在降低面向用户的服务（订单服务）的延迟的同时，解耦了各服务。

这种方式可以达到最终一致性，但过程可能较慢。

在保存订单后，将其发送给发票服务。

与之前的模式不同，这种方法试图处理整个分布式事务。

它需要某种类型的编排服务，这种编排服务可能是一个单独的服务或某个其他存在的服务。

此外，它还需要补偿事务。

各个服务发出事件，其他服务侦听这些事件去更新自己的数据。

你保存了订单，并发出一个“订单已创建”的事件。

发票服务侦听这些事件，根据订单创建新的发票。

服务之间不需要互相了解，可以独立扩展。

一言以蔽之，

背景同步模式提供了简化流程和解耦服务的优势，但可能带来数据一致性的延迟。

基于请求的编排模式提供了可控流程和可靠性，但可能增加响应的时间。

基于事件的模式带来了松耦合和可扩展性，允许服务对变化做出反应，但可能引入复杂性。

最终一致性是为了更高的性能、可扩展性和可用性所必须付出的代价。

你更倾向于哪一种呢？如果对微服务和服务治理感兴趣可以关注我的专栏了解更多实用知识点。