微服务应该如何处理 409 响应？答案

【问题标题】：How should a 409 response be handled by a microservice?微服务应该如何处理 409 响应？
【发布时间】：2020-05-09 08:19:23
【问题描述】：

考虑两个微服务“A”和“B”。假设“A”对“B”进行 POST 调用，“B”执行基于某个 id 检查重复请求的操作。如果操作成功，“B”返回 200 OK 响应。如果“B”发现请求是重复的，则返回409。

现在考虑一个场景，其中“A”对“B”进行 POST 调用。 “B”成功处理，但在响应之前，连接超时，“A”收到504 超时错误代码。当服务“A”重试请求时，这次“B”将其识别为重复请求并返回409 响应，因为它已成功处理“A”发出的第一个请求。在这种情况下，服务“A”应该将此视为不可重试的错误，还是应将其视为成功（假设其第一个请求已成功处理）？

【问题讨论】：

标签： http error-handling microservices error-code

【解决方案1】：

..."B" 将此识别为重复请求并返回 409 响应...在这种情况下，服务“A”应将其视为不可重试的错误还是应该将其视为成功...

来电者能否就 409 状态是由其先前呼叫的“成功”还是由其他类型的“冲突”引起的得出明确的结论？我不知道，但我可能不希望我的处理依赖于此。

是否应该将任何 4xx 响应状态视为“可重试”，这是值得怀疑的。在我看来，处理应该假设调用永久失败。

【讨论】：

有时网络故障会导致连接重置，这可能会导致向调用者（“A”）返回 5xx 代码。在这种情况下，微服务“B”可能无法知道调用者（“A”）没有得到 2XX，而是得到了 5XX 代码。
@adi 我同意这可能发生。但是，正如您在问题中指出的那样，网络故障非常罕见，并且由重试策略处理。但是，我已经删除了答案的第一部分，因为它不在此处。

【解决方案2】：

我从您的 Q 中了解到，即使发生超时，B 仍将下一个呼叫识别为重复呼叫。首先，不要依赖/依赖它作为成功。我宁愿寻找该状态在哪里维护？它存储多长时间，在超时的情况下，可以释放该状态还是必须从 A 触发检查以了解该事务是否实际成功？例如，A 发布客户信息，B 超时。现在，在重试之前，调用 getCustomerInfo(customerName, customerId, x,y,z,...) 来验证即使发生超时，Post 最终还是成功了。

此外，您可能想深入了解保留多长时间、B 处重复 ID 的状态，以及您是否可以与 B 团队合作提前发布此内容以进一步进行？

我还看到了在微服务 A 和 B 团队之间进行编排的机会，在这种情况下，排队服务可以证明是非常有益的（只有在这种情况经常发生的情况下）。

【讨论】：