第五章: 超越回调: 5.2 回调

5.2 回调

我们将首先使用回调来实现边缘服务，就像我们从本书开始以来一直在做的那样。

我们项目所需的依赖项是 Vert.x Core、Vert.x Web Client（用于简化 HTTP 请求）和 Logback。 以下清单显示了 Gradle 构建的依赖项。 使用 Maven 或任何其他兼容的构建工具时，工件完全相同。

🏷注意: 除了 chapter5.future.CollectorService 之外的所有类都在 Vert.x 3.9 上编译。 此类需要较新的基于 Vert.x 4 future的 API，如第 5.3.2 节中关于 Vert.x futures 和 promises 的部分所述。

5.2.1 实现

我们将从 CollectorService verticle 类实现的序言开始。

start 方法首先创建一个 WebClient 实例，然后在端口 8080 上启动一个 HTTP 服务器。Web 客户端类来自 vertx-web-client 模块，与 Vert.x 核心 API。 它特别简化了 HTTP 正文处理和转换：您可以将正文转换为纯文本、JSON 或通用的 Vert.x 缓冲区。

HTTP 请求处理程序是以下清单中显示的 handleRequest 方法。

此方法显示使用 Web 客户端 API 执行 HTTP 请求是多么容易。 主要困难在于协调并行 HTTP 请求。 我们需要一个循环来发出请求，并且由于它们是异步的，我们还需要跟踪接收到的响应数量和响应值。 这是通过拥有一个响应列表并使用一个计数器进行响应来完成的。 请注意，我们在这里使用 AtomicInteger 不是因为并发性，而是因为我们需要一个对象来从回调中增加一个整数。

收到所有响应后，我们可以进行下一个操作，即将数据发送到快照服务。

此方法实现仅使用 Web 客户端发出 HTTP POST 请求。

成功后，代码将移至 sendResponse 方法以结束 HTTP 请求，如下所示。

5.2.2 运行

要运行边缘服务，我们首先需要部署 Verticle，如下面的清单所示。

我们可以发出 HTTP 请求以使用 HTTPie 测试服务，如下所示。

在服务器端，我们可以检查快照服务是否输出了一些日志，如下面的清单所示。

5.2.3 “回调地狱”不是问题所在

很多人会尖叫“回调地狱！” 在讨论回调时。 回调地狱是当嵌套回调被用于链接异步操作时，由于深度嵌套导致代码更难理解。 对于嵌套回调，错误处理尤其困难。

虽然这是真的，但是对于每个异步操作回调使用一种方法可以轻松缓解回调地狱，就像我们对 handleRequest、sendToSnapshot 和 sendResponse 方法所做的那样。 每个方法只做一件事，我们避免嵌套回调。

下面的清单显示了与前面相同的代码，但压缩为带有嵌套回调的单个片段。

嵌套回调当然不会使代码更具可读性，但我认为真正的问题在于功能代码与异步协调代码纠缠在一起的事实。 您需要从循环、回调和分支中解读出三个 HTTP 请求是并行发出的，并且它们的结果正在组合、发送到第三方服务，然后作为响应返回。

回调并不完美，但是一些规则可以保持代码的可读性，特别是当您所拥有的只是异步操作的顺序组合时，比如sendToSnapshot将工作传递给sendResponse。

现在让我们看看其他比回调更有趣的异步编程模型。