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

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设置。