microservices - 基于微服务的架构中的最终一致性暂时限制了功能

Question

我将用 Twitter 说明我的问题。例如，Twitter 具有基于微服务的架构，这意味着不同的进程位于不同的服务器中并具有不同的数据库。

出现一条新推文，服务器 A 在其自己的数据库中存储了一些数据，生成了新事件并触发了它们。服务器 B 和 C 此时没有收到这些事件，也没有在他们的数据库中存储任何东西，也没有处理任何东西。

创建推文的用户想要编辑该推文。为实现这一点，所有三个服务 A、B、C 都应该处理所有事件并将所有需要的数据存储到 db，但服务 B 和 C 还不一致。 这意味着我们目前无法提供编辑功能。

如我所见，一种可能的解决方法是切换到即时一致性，但这会带走所有基于微服务的架构优势，并且可能会导致紧耦合问题。

另一种解决方法是在一段时间内限制用户的操作，直到所有必要服务的数据不一致为止。可能是一个解决方案，取决于客户及其业务需求。

另一种解决方法是添加额外的逻辑或可能的服务 D，将编辑存储为用户的操作，并仅在它们一致时将它们应用于数据。缺点是大大增加了系统的复杂性。

还有两阶段提交，但那是 1) 不太可靠 2) 慢。
我认为在 Twitter 这样的负载情况下，速度慢是一个巨大的缺点。但它可能可以得到解决，而缺乏可靠性又不能不增加解决方案的复杂性。

所以，问题是:

1. 对于图示的情况是否有任何好的解决方案，或者只有我提到的解决方法？也许是一些编程平台或数据库？
2. 我是否误解了什么，一些解决方法不正确？
3. 除了最终一致性之外，是否有任何其他方法可以保证存储所有数据并由其他服务执行所有必要的操作？

为什么为这个用例选择最终一致性？正如我所看到的，如果我们谈论事件驱动方法时，当某些服务将在某些事件被触发时开始工作时，这是保证某些数据将被存储或某些操作将被执行的唯一方法，并且按照我的例子，该事件将是“tweet is created”。因此，如果服务 B 和 C 出现故障，我需要能够在它们再次启动时成功执行操作。

我想达到的目标是:可靠性、承受高负载的能力、足够复杂的解决方案。非常感谢有关任何相关主题的任何链接。

如果这种方法有天然的局限性，并且我想要的东西不能用这种范式实现，那也没关系。我只需要知道这个问题真的还没有解决。

Answer 1

一切都是权衡取舍。在您的示例中使用最终一致性可能意味着用户可能无法编辑几秒钟，因为大多数最终一致的技术不会花费太长时间来跨节点复制数据。因此，在这个用例中，这是绝对可以接受的，因为用户的操作非常缓慢。

例如:

MongoDB is consistent by default: reads and writes are issued to the primary member of a replica set. Applications can optionally read from secondary replicas, where data is eventually consistent by default.

from official MongoDB FAQ

另一种越来越流行的替代方法是使用流媒体平台，例如 Apache Kafka，这取决于您的架构设计流消费者处理数据的速度(以实现最终一致性)。由于流平台非常快，它主要取决于流处理器的速度才能在正确的位置提供数据。所以在大多数情况下，我们谈论的是毫秒而不是秒。