使用scala和play2或spray进行异步回调

我有一个系统设计挑战，我想得到一些社区反馈

基本系统结构：

[客户端]--HTTP-POST-->[REST服务]-->[Queue]-->[Processors]

• [Client]将json发布到[REST服务]进行处理
• 根据请求，[Rest Services]将数据发送到各种队列，由不同的处理器以不同的语言编写并在不同的进程中运行
• 每个处理器中的工作都是并行的，但仍然需要30秒的时间来处理。处理时间是数据复杂性的函数，无法加快
• 结果在完成时无法流式传输回客户端，因为只有在所有子步骤完成后，才能完成最后的后处理步骤

关键挑战：完成后处理后，客户需要：

• 在客户端等待后发送结果
• 通知async作业已完成并传递id以请求最终结果

设计要求

我不想阻止[REST服务]。它需要接收传入请求，将数据路由到适当的队列，以便在其他进程中进行处理，然后立即可用于下一个传入请求

通常我会使用演员和/或期货/承诺，这样在等待后台工作人员完成时，[REST服务]不会被阻止。这里的挑战是，从事后台工作的工作人员在不同的进程/虚拟机中运行，并编写在不同的技术堆栈中。为了在异构系统之间传递这些消息并确保请求生存期的完整性，正在使用持久队列（而不是内存中的消息传递或RPC）

最后一点需要考虑的是，为了扩展，在各自的池中有一组负载平衡的[REST服务]和[Processors]。因此，由于从[REST服务]到[Processor]的消息需要通过队列异步发送（所有正在运行的都是单独的进程），因此无法将后台[Processor]中完成的工作关联回其原始调用[REST服务]实例，以便在promise或actor消息中返回最终处理的数据，并最终将响应传递回原始客户端

所以，问题是，如何进行这种关联？一旦所有后台处理完成，我需要通过等待已久的响应或通知将结果返回给客户端（我不想使用类似UrbanAirship的东西，因为大多数客户端都是浏览器或其他服务）

我希望这是清楚的，如果没有，请要求澄清

编辑：可能的解决方案-想法？

---

我认为我将spray RequestContext传递给任何参与者，然后这些参与者可以响应回客户端（不必是接收HTTP请求的原始参与者）。如果这是真的，我是否可以缓存RequestContext，然后在处理完成后使用它将响应异步发送到使用此缓存的RequestContext的相应客户端？

嗯，这不是最好的，因为它需要客户端做更多的工作，但听起来您希望实现一个。因此

[客户端]--POST-->[REST服务]-->[Calculations]-->POST[客户端]

[客户]——获取

解释如下：

---

客户端向您的服务发送POST请求。然后，您的服务将执行任何必要的处理。完成后，您的服务将向客户端已设置的URL发送HTTP-POST。使用该POST数据，客户端将获得必要的信息，然后对完成的数据执行GET请求。

好吧……生成UU您发送给处理器的所有内容的ID，以及每当处理器向结果队列生成某些内容时，它们都会指定此UUID。@SarveshKumarSingh是的，我们生成一个“作业ID”（UUID）创建请求并将其包含在所有消息中时，以便可以关联最终生成的数据。以立即响应的方式将此id发送回客户端将起作用，但我不希望在结果准备就绪之前进行客户端轮询。我希望在原始[REST Service]实例上获取原始调用上下文（以非阻塞方式）在所有后台处理完成后，使用收到的承诺或akka消息的结果进行响应。核心问题是如何进行此关联？您不是在寻找关联。您正在寻找一种方法来回复客户端。您可以选择套接字之类的内容，也可以将最终输出发布到结果ts队列并让客户端从中选择结果。@SarveshKumarSingh我们已经将最终结果发布到队列中。问题是：我不希望客户端必须轮询作业id。我希望以非阻塞方式回复客户端当计算最终结果时。这将需要我用akka消息响应，或承诺返回[REST Service]的实例，以便它可以将响应发送回调用客户端。这就是我想做的-我认为这需要我匹配（或关联）完成的作业，最终的计算结果返回给调用的客户端。由于您使用的是辅助服务，我认为您的作业需要花费很多时间，或者某些作业将等待工作人员拾取。这意味着您不希望以服务器接收请求并通过h结果。因此…您希望有一种与客户端通信的方式，而无需客户端向您的第一个客户端发送请求（轮询通过不断发送请求来工作）。实现这一点的最常用方式是套接字或消息队列。因此，请告诉您的客户端连接到消息队列并发布到sa