乐趣区

Java中的GraphQL服务器第三部分提高并发性

jiezi

GraphQL 的思想是通过将多个通常不相关的请求批处理到一个网络调用中来减少网络往返的次数。通过一次传送许多信息，大大减少了等待时间。当多个顺序的网络往返可以用一个来代替时，它特别有用。好吧，老实说，每个网络浏览器都会自动为我们完成此操作。例如，当我们打开一个包含多个图像的网站时，浏览器将同时发送每个图像的 HTTP 请求。或者，确切地说，它将开始不超过与同一主机的一定数量的连接。介于 2 到 8 之间，具体取决于浏览器。同样适用于多个 AJAX / RESTful 调用（请参阅fetch()API），默认情况下是并发的，开发人员方面无需进行任何额外的工作。实际上，这就是_A_在 AJAX 1 中的含义。

那么，GraphQL 有什么优势？

如果 Web 浏览器已经可以同时对多个数据发出并发请求，为什么还要麻烦 GraphQL？有一些优点：

  • 如果您需要进行的并发连接数量超出允​​许的数量（最多 2 - 8 个，请参见上文），浏览器无论如何都会限制您的工作，从而使一些请求排队
  • GraphQL 通过仅返回您明确要求的属性和关系来防止过度获取和 N + 1 问题，不多，也不少
  • 只有一个批处理请求。并发发生在服务器端。好吧，不是真的 …

GraphQL 服务器默认情况下不使用并发

默认情况下，在 Java 的 GraphQL 服务器实现中，最后一句_不正确_。记住，我们为每个非平凡的属性和关系提供了很多解析器。提醒一下，这是我们的解析器的外观：

@Component
class PlayerResolver implements GraphQLResolver<Player> {Billing billing(Player player) //...
    String name(Player player) //...
    int points(Player player) //...
    ImmutableList<Item> inventory(Player player) //...

}

这些方法中的每一个仅在需要时才被调用，并且每个都是潜在的重量级。不幸的是，默认情况下，服务器端的 GraphQL 引擎会顺序调用解析器方法。因此，与 RESTful API（！）相比，总体延迟要差得多。Restful API 将利用浏览器的内置并发性。为了显示这种行为的糟糕程度，我设置了 Zipkin 并跟踪了每个解析器：

请注意，完全不相关的解析程序彼此之间是如何等待的。幸运的是，此性能瓶颈很容易解决。原来 GraphQL 引擎了解CompletableFuture！

异步解析器

看看经过改进的解析器 API：

@Component
class PlayerResolver implements GraphQLResolver<Player> {CompletableFuture<Billing> billing(Player player) //...
    CompletableFuture<String> name(Player player) //...
    CompletableFuture<Integer> points(Player player) //...
    CompletableFuture<List<Item>> inventory(Player player) //...

}

并发的来源在这里并不重要。有可能：

  • Java 的 9 分的HttpClient，
  • 专用线程池，
  • 从反应器的反应转换 Mono 使用Mono.toFuture()，
  • Deferred使用 Kotlin 的 [] 对象进行转换asCompletableFuture()
  • …

关键是，GraphQL 考虑了这一未来，并同时调用多个解析器。看看 Zipkin 的效果如何：

此图像教给我们两件事：

  • 整体延迟从 1.1 秒降至 0.6 s- 所有延迟之和与最大延迟之和
  • 甚至更重要的是 - 您是否注意到缓慢的 inventory 解析器对总延迟的影响最大？也许，作为客户，您可以跳过该属性并将等待时间减少一半？

GraphQL 为客户提供了绝佳的机会来以细粒度的方式自定义其查询。您要决定要多少数据。API 生产者不再负责。同样，API 不必是最低公分母。每个客户都做出独立的决定，而不是_一个合适的选择_。最后但并非最不重要的一点是，能够轻松地描述每个解析器是一个巨大的胜利。GitHub 上提供了本系列所有文章
的完整源代码，包括 Docker 上的 Zipkin 设置。

退出移动版