微服务范围内的请求原子性

Question

我们的项目包含多个微服务。这些微服务形成一个边界，没有严格定义入口点，这意味着可以请求每个微服务，也可以请求其他服务。

在这种有限的微服务上下文中，我们需要处理的情况如下： 客户端（其他应用程序）发出执行某些逻辑并更改数据的请求（PATCH）， 请求超时， 在处理请求时，客户端会触发相同的请求以重复操作， 操作成功完成， 第二个请求将以相同的方式处理并在其时间内完成，客户端会得到响应。

现在发生的事情是，由于第一次超时，相同的文件被处理了两次。

我们需要确保不会处理相同的请求，并且应用程序将使用以前的响应和状态代码进行响应。

后续请求由同一uuid标识。

现在，我知道应该由客户端来做更精确的请求，或者在micorservices受限的上下文中我们应该有一个请求入口点，但是在企业项目中，团队并不拥有整个系统，因此我们有点受限我们针对该问题提出的解决方案。考虑到这一点，而又不想重新发明轮子，这在我脑海中浮现：

微服务应该利用某种会话共享（spring-session？），并具有在处理之前以及在所述情况下（第一个正在处理而第二个到达）的id查找请求的能力。 ，等待第一个操作完成，然后用第一个对客户端超时的数据响应第二个操作。

我正在努力想象如何处理第二个请求的异步性以及如何侦听第一个请求的会话状态。

如果将使用spring-session（例如，使用hazelcast），则我缺少某种具体的会话状态处理程序，该处理程序在请求结束时会被触发。有这样的事情要听吗？

尚无代码。我想讨论这是一个建筑思想实验。

如果不确定理解，请再读一遍，我很乐意扩展。

编辑：第一个想法：

过程如下（在图像上带有编号）：

• （1）第一个请求被触发
• （3）处理开始； （2）请求同时超时；
• （4）客户端重复相同的请求；程序知道它之前已经收到相同的请求，因为它知道请求。 ID。
• 程序检查缓存和该请求ID“待处理”的状态，以便等待（异步）。
• 第一个请求的计算结果保存到缓存中-橙色正方形
• （5）程序使用第一个请求的数据来响应第一个请求

想法是结果检查和对重复请求的响应将在过滤器链中完成，因此当第二个请求异步等待第一个请求触发的操作完成时，它实际上不会击中控制器（我当从缓存中添加/更新/退出行时，看到hazelcast发生了一些事件-dunno（如果它仍在工作），并且完成后仅响应（以某种方式写入HttpServletResponse）。结果将保存到postHandling过滤器的缓存中。

感谢您的见解。

Answer 1

我认为这更多是一种缓存范例。将您的请求/响应放入由uuid索引的外部缓存提供程序（REDIS或类似内容）中。拥有TTL将使您的响应自动得到清理，以应对永远不会回来的请求，而高速实施（o1）应该可以很好地扩展它。它将立即为您提供异步模型（不是既定目标，但总是一个不错的选择）。