假设您有一个服务A，它是大型微服务架构的一部分，这些服务通过REST API或通过涉及某些代理的消息（RabbitMQ）相互通信。服务A公开需要与某些第三方服务进行通信的REST端点（对于不在我们架构中的服务）以及在那里创建一些内容，当服务A收到来自第三方的响应时一切都很顺利，它应该在自己的数据库中保留来自该响应的一些数据。
考虑到第三方不提供任何幂等机制，最好的方法是覆盖以下问题。
第三方的创建进展顺利，但DB写入服务A失败。这会导致状态不一致，你在第三方创建了一些东西，但你在自己的数据库中没有关于它的所需数据。
您收到第三方的超时，因此您不能只是重复通话，因为他们没有提供任何幂等机制。如果您重复通话，可能会以两个（或更多）创建的资源结束，而不是一个。
问题编号1.可以通过任何重试机制解决，该机制可以无论多次重试DB调用。该方法的问题在于，如果重复数据库调用的服务A实例突然停止运行。
据推测，更好的方法是在第三方成功创建服务后，发布关于成功创建的RabbitMQ消息。此服务将侦听该消息，并且在收到消息时可以进行数据库调用。具有良好的重试机制并利用确认消息，可以解决有关What if service instance goes down suddenly的问题。 因此，此解决方案服务是其自己的消息的发布者和消费者。任何更好的主意？此解决方案还将引入最终一致性，因为API调用者（正在调用服务A端点的人）将在第三方成功创建后立即收到响应 ，但之前服务数据库中存在任何内容（实际上API客户端需要什么）
超时问题怎么样？ 在这种情况下如何处理来自第三方的超时？。我没有看到比发出GET调用更好的事情来检查他们是否创造了一些东西。 GET调用再次失败，但可以重复，直到成功为止。在这里，边际用例也就是如果服务在发出GET调用时发生故障。