如何确保事件驱动的微服务体系结构中的持久性？
现在，我们有一组微服务，它有一个面向客户端的网关，负责身份验证和路由。MySQL数据库和消息队列的RabbitMQ。内部服务可以根据需要对请求进行排队，但网关从来没有这样做过。我发现网关回应的时间太长了。我希望将来自网关的消息排队到异步整个系统，并生成更快的响应时间，但我不知道如何保证持久性，以便我们能够处理失败。我没有实际的数据库记录，我不知道它如何处理正确的持久性。
简而言之:完全事件驱动的体系结构如何保证数据的持久性。用一个具体的例子来说明会更容易一些。
我们收集收入记录，然后允许人们根据他们的收入付款。我们有一个端点来创建收益记录。如下所示：
客户端->网关->收益服务
问题是这一切都是同步的。收入服务电话要花太长时间才能做完所有的工作。它必须写一些记录，做检查，以确保数据是有效的，等等。还有其他异步部分，但这部分没有。
如果我在网关排队，那么还没有数据库记录。第一个记录是在收益服务中写入的。在我们的同步系统中，这很好，因为我们保证200级响应的记录。如果我开始在网关排队，我现在需要确保没有db记录就不会丢失消息。我该怎么做？
有什么办法可以保证兔子的坚持吗？消息数据库是一种选择吗？我们的端点是幂等的，所以在灾难恢复情况下，我们可以在不受伤害的情况下重播消息。我只是不知道该怎么做。谢谢
回答 2
Software Engineering用户
发布于 2019-04-21 16:30:12
您想要保证持久性在创建记录时就成功了吗？为什么？
对客户来说，知道请求是有效的，并且收益服务现在或以后会处理所有其他事情，这似乎就足够了。
根据这种逻辑，您可以首先在收益中验证该请求，这通常是一种非常快速的操作，如果有问题，可以立即响应验证错误。如果请求有效，则将其存储在队列中，并让收入的另一部分处理这些请求以创建记录。
现在，如果持久性失败，收益服务可以轻松地在稍后重放失败的事件，并且客户端知道它正确地完成了它的工作，这就是发送正确的请求。
Software Engineering用户
发布于 2021-12-13 12:48:41
- API接受请求。
- 如果请求无效，则返回验证异常。
- 如果经过验证，返回201 (已创建) =>将事件发送到消息总线，并允许幕后的其他进程创建DB记录
它真的不需要比这更复杂。
要了解作为流程的一部分创建了哪些记录，请调用API以获取记录。当您完成该调用时，记录将从您的其他进程中保存在数据库中。从用户的角度来看，这种情况发生得很快，因为首先调用是异步保存记录的，并且UI保持响应。
https://softwareengineering.stackexchange.com/questions/390709
复制相似问题
腾讯云开发者
