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

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

一条新的tweet出现了，服务器A在自己的数据库中存储了一些数据，生成了新的事件并触发了它们。服务器B和C此时未获取这些事件，也未在其数据库中存储任何内容，也未处理任何内容

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

正如我所看到的，一个可能的解决方法是切换到即时一致性，但这将带走所有基于微服务的体系结构优势，并可能导致紧耦合问题

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

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

有两个阶段的提交，但这不是真正可靠的2）慢。
我认为在Twitter这样的负载情况下，速度慢是一个巨大的缺点。但它可能是可以解决的，而缺乏可靠性，同样，如果不增加解决方案的复杂性，就无法解决

因此，问题是：

有没有什么好的解决方案，或者只有我提到的解决办法？也许是一些编程平台或数据库

我是否误解了某些东西，有些变通方法不正确

除了最终一致性之外，是否还有其他方法可以保证所有数据都将被存储，所有必要的操作都将由其他服务执行

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

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

---

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

这都是权衡问题。对于示例中的最终一致性，这可能意味着用户在几秒钟内无法编辑，因为大多数最终一致性技术不会花费太长时间跨节点复制数据。所以在这个用例中，这是完全可以接受的，因为用户的动作非常缓慢

例如：

MongoDB在默认情况下是一致的：读取和写入都是向 副本集的主要成员。应用程序可以选择从 辅助副本，默认情况下数据最终是一致的

---

另一个越来越流行的替代方案是使用流媒体平台，如ApacheKafka，其中流消费者处理数据的速度取决于您的体系结构设计（最终的一致性）。由于流平台的速度非常快，因此通常只有流处理器的速度才能使数据在正确的位置可用。因此，在大多数情况下，我们谈论的是毫秒，而不是秒。

在这类体系结构中，关键是让每个服务在写入时都是自主的：即使其他应用程序级服务都没有启动，它也可以进行写入

因此，在类似twitter的服务示例中，您可以将其建模为

Service A manages the content of a post

因此，当用户发表文章时，服务a的数据库中会发生写操作，从那一刻起，文章就可以被编辑，因为编辑只是对服务a的一个请求

---

如果有其他服务使用来自“新帖子”事件的“帖子内容”更改事件，并且在“新帖子”事件公开某些功能后，该功能将不会公开，直到该服务看到该事件（耶，重言式）。但这只是物理学：太阳可能在五分钟前变成超新星，在我们“看到光”之前，我们不能采取任何行动（不是我们可能采取的行动）。

虽然这是一个非常有趣的话题，但这似乎不是一个有效的SO问题。@ConstantinGALBENU这是关于编程的，它描述了具体的问题。它甚至不是基于意见的，因为提到了解决方案的特定要求。为什么这不是一个有效的问题？看起来像是关于编程范式或开发模式的任何其他问题。在您给出的特定示例中，我宁愿选择将tweet存储在公共数据库中，并使用直写数据网格与之交互。因为需求要求我们拥有公共数据存储。“大多数最终的一致性技术不会花费太长的时间”。它可能需要任何时间，从几分钟到几天：网络问题、第三方服务问题、维护；任何事情都可能减慢处理速度。甚至流媒体在这方面也没有帮助。