为什么队列涉及 API 设计答案

【问题标题】：why Queues involves API design为什么队列涉及 API 设计
【发布时间】：2018-07-15 20:16:32
【问题描述】：

我看到有人在写restful api的时候，把控制器层和数据库访问层分开，让他们通过队列（比如ActiveMQ）相互通信。这是为什么？这种设计是否提高了吞吐量？或者这样做有什么好处？谢谢。

【问题讨论】：

如果有人真的热衷于微服务，他们可能会将 restful 服务拆分为一个单独的应用程序，而不是写入数据库的应用程序。优点是您可以独立于另一个应用程序更改（和部署）一个应用程序 - 但是，正如您所注意到的，同步（现在是 2 个或更多）应用程序的操作会增加复杂性和开销。

标签： java rest message-queue restful-architecture

【解决方案1】：

我想不出一个正确设计（从头开始）的架构，其中所描述的内容是有意义的。数据库和队列具有相同的通用目的（存储），但数据库用于长期存储和检索，而队列用于短期缓冲。

当可用处理能力与客户请求之间存在短期不匹配时，您将事情排入队列。将请求排队到微服务是非常有意义的。此外，大多数 Web 服务器都有一个内置的请求队列。

简单地对数据库操作进行排队意味着您的数据库无法满足您的吞吐量需求。这是一个队列无法解决的永久性问题。请求应直接访问数据库，Web 服务代码应直接调用 DAL 方法。数据库操作的任何排队最好留给数据库引擎本身。

【讨论】：

【解决方案2】：

工程师可能采用 REST 服务将内容发布到 JMS 队列的架构的一个原因是避免让 REST 客户端等待长时间运行的操作。客户端改为提交数据进行处理（例如将数据保存到数据库中），并快速响应该信息已被接受以供将来处理。

例如，可以使用POST 上传大文件：

curl -X POST -H "Content-Type: application/json" -d @myFile.json localhost:8080/upload

REST 服务可以将内容放入 JMS 队列，然后立即返回 HTTP 状态代码 202，让客户端知道消息已被接受。它还可以提供信息以通过Location 标头检索处理过的数据。

Location: 2112

如果服务由于某种原因无法接受数据，则需要返回错误代码。

REST API 可以允许稍后通过GET 方法检索已处理的资源：

curl localhost:8080/processed/item/2112

如果项目尚未准备好，服务可能会返回状态 202（已接受）。稍后，当它准备好时，服务可以连同数据一起返回状态 200（OK）。

更新：如下所述，如果您正在做的唯一事情是使用 REST 调用中接收到的信息更新数据库中的数据，那么这是不推荐/有用的。我更广泛地回答了这个问题，并假设在持久化数据之前需要进行其他处理。

【讨论】：

谢谢@Mike。现在我很好奇你描述的202场景。通常，这有什么帮助？所以在我的客户端，我应该在一个时间间隔内获取已处理的项目状态，直到我获得成功（200）或失败（如 500）。我对吗？如果是这种情况，你能给我一个例子，它是如何在现实生活中使用的吗？很抱歉给您带来麻烦。
POST 上传 API 返回 202 以确保客户端知道服务已接受信息并将其发布到 JMS 队列。但是如果您不喜欢 202，您可以返回 200。服务将使用任何其他响应来告诉客户端它不接受信息并且没有处理它。 400 表示客户端发送了错误信息。 500 表示服务存在问题。
如何设计解决方案的其他方面确实取决于您要实现的目标。在答案中，我只是想举例说明如何通过 REST 检索处理过的数据。但是该服务也可以将处理后的数据发布到原始程序/应用程序从中读取的另一个队列。或者，在确认数据已提交后，原始应用程序可能不在乎。也许有一个 UI 和一个用户参与......等等。
谢谢。我得到了我提到的代码开始，使用邮递员向它发送一个发布请求，并在数据访问服务端（队列的消费者端）放置一个调试点。根据您的解释，我希望调试点会被命中，但邮递员请求不会被阻止（应该立即完成）。但是，我注意到邮递员的请求正在等待响应。我错过了什么吗？
没有看到很难确定哪里出错的代码。但这似乎是一个不同的问题。这个人问为什么有人可能想要构建一个将 REST 写入 JMS 队列的解决方案。