Java 中的响应式系统

第 8 章 HTTP 考虑到反应的 HTTP

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

即使在构建反应式系统时，HTTP 也是不可避免的。 HTTP 是一种流行的协议，例如，REST 就是一种众所周知的服务和 API 设计方法。如第 4 章所述，HTTP 的问题在于请求/响应交互方案会导致不理想的时间耦合。 此外，要实现空间解耦，通常需要代理来路由请求或高级服务发现和负载平衡机制。

但是，我们必须面对现实：我们需要务实，HTTP 有很多强大的功能。 我们建议在系统边缘（与外部实体交互的地方）使用 HTTP，如图 8-1所示。 例如，HTTP 通常用于前层，以公开易于其他外部服务使用的 API。 此外，我们还经常在与其他外部服务的各个集成点使用 HTTP，如使用 REST API 公开的服务。

集成 HTTP 不应该妨碍或限制你正在构建的反应式系统的响应能力。 因此，我们需要谨慎地实现这种集成。 使用所谓异步 HTTP 客户端的系统并不少见，但这种客户端可能弊大于利，因为它可能依赖于一个隐藏的线程池。

图 8-1. 在反应式系统边缘使用 HTTP

本章将探讨 Quarkus 提供的暴露 HTTP 端点的功能，以及我们实现这些端点的方法。 在图 8-1 中，这部分用虚线圈出；右侧的 HTTP 服务消耗将在第 12 章中介绍。

HTTP 请求的旅程

要了解使用 Quarkus 以反应式方式处理 HTTP 的好处，我们需要了解一下它的引擎盖。 如第 6 章所示，Quarkus 是基于反应式引擎的，因此 Quarkus 的每个方面都受益于该引擎提供的异步和非阻塞功能。 当然，这也包括 HTTP。 不过，虽然我们在之前的 Quarkus 应用程序中实现了 HTTP 端点，但代码并没有受益于该引擎提供的所有功能。 让我们来看看 Quarkus 是如何处理 HTTP 请求的，以及我们可以在哪些方面释放反应式引擎的威力。

要处理 HTTP 请求，你需要一个 HTTP 服务器。 该服务器监听一个特定的端口（在 Quarkus 中为 8080）并等待传入连接。 当服务器收到一个新连接时，它会读取帧并组装 HTTP 请求。 通常情况下，服务器会解析 HTTP 方法（例如GET 或POST ）、调用路径、正文等。多个帧可以组成一个 HTTP 请求，大的正文会被分割成多个帧。

一旦组装好 HTTP 请求，Quarkus 就会决定如何处理它。 它会检查拦截器（以处理安全或日志问题），并寻找可以处理请求的端点。 这种查找基于路径，但也可以包括内容类型协商。 一旦找到端点方法，Quarkus 就会调用该方法，并由该方法来处理请求。

假设我们调用了一个同步方法，该方法的结果就是 HTTP 响应的有效载荷。 Quarkus 会捕获该结果并构建一个 HTTP 响应，然后将响应写入相应的 HTTP 连接，并对内容进行相应的编码。

到目前为止，一切都很好，但还不够反应迅速，对吧？ HTTP 服务是这种交换的重要组成部分之一。Quarkus 使用的 HTTP 服务器是非阻塞、高效和并发的。它由 Vert.x 提供支持，通过使用 I/O 线程来处理 HTTP 交互。因此，它遵循了我们之前在图 4-1中解释的反应迅速的方法，可以使用少量线程处理多个 ...