【.com快译】GraphQL作为REST的替代品，自2015年发布以来，为前端开发者提供了他们渴望已久的灵活性。他们可以通过一个定义所有需要的数据一次性查询，并且可以一次性“打包”获取，大大减少了等待时间。除了简化前端，REST还让监控之类的事情变得更容易。基于此，后端团队可以考虑各个端点的状态，及时发现当前的问题。当然，在使用过程中，我们需要考虑清楚的最关键的问题是：如何使用GraphQL准确监控目标系统的重要位置。接下来，让我们讨论一些监控GraphQLAPI的良好实践。GraphQL架构为了弄清楚以上问题，我们先来了解一下GraphQL的架构。通常，一个简单的GraphQL系统会包括以下三个部分：定义所有数据类型的模式（结构模式）。一个GraphQL引擎，它使用模式将查询的每个部分路由到解析器。GraphQL引擎可以调用的一个或多个解析器。通过解析模式，GraphQL后端让服务器知道哪个解析器可以处理哪种类型的查询。也就是说，当查询被发送到GraphQL端点时，GraphQL引擎解析查询中的每个请求类型，然后调用解析器来满足其请求。可以想象，此类方法在用于简单查询时仅限于提供良好的性能。有时，查询的某些部分会连接到同一个数据源（包括数据库或第三方API等）。例如，如果我们加载一个用户的账号和他们的地址，他们在GraphQLschema中可能有两种类型，但在数据源中只有一种记录。那么当我们同时发送请求时，当然不希望服务器向同一个数据源发送两个查询请求。为了解决以上问题，业界会采用一种称为数据加载器（data-loader）的模式。数据加载器是位于解析器和数据源之间的另一个GraphQLAPI层。通过简单的设置，解析器将能够直接访问数据源。在更复杂的迭代中，解析器准确地告诉数据加载器他们需要什么，然后加载器为此目的访问数据源。好吧，这样做的好处是数据加载器可以继续等待，直到所有解析器都被调用并且完成对数据源的访问。对于上面提到的例子，如果有人要加载用户的帐号和地址，那么只需要向数据源发出请求即可。可以看出解析器只需要了解其相应的需求，而数据加载器需要知道所有解析器的用途，并据此优化具体的访问。监控GraphQL有了以上的理论基础，我们可以根据自己的架构，在以下几个位置监控GraphQLAPI：HTTP端点：所有影响我们API的流量。GraphQL查询：针对每个特定查询。GraphQL解析器或数据加载器：用于对数据源的每次访问。全栈跟踪：哪些解析器和数据加载器受到每个查询的影响。1.HTTP端点在GraphQL架构中，通常只有一个HTTP端点，所以在RESTAPI层面的监控往往只能给我们API的整体状态信息。当然，这只是我们监控的一个起点。如果能够提供低延迟、低错误率的全量信息，并且客户端没有任何投诉，那么这些指标可以为我们节省大量的时间和精力花在后续的深度监控上。但是，如果某个地方有问题，我们需要更深入地挖掘。2.GraphQLquery接下来，我们需要监控每一个query，当然，主要针对静态使用模式的API。如果我们仅将API与我们自己的客户端一起使用，则对固有查询的更改通常不会经常发生。而如果我们的API需要处理来自不同客户端的不同请求，那么查询请求不仅多，而且复杂。这些细微的请求往往会减慢整个过程。消除此类问题的一种方法是检查最常见的查询并对它们实施综合监控。这意味着我们需要预先定义一整套查询和变量组合，然后从测试客户端运行它们，看看它们需要多长时间。基于此，我们能够减少更新期间严重影响性能的风险因素。由于持久化查询（Persistedqueries,https://blog.apollographql.com/persisted-graphql-queries-with-apollo-client-119fd7e6bba5）可以缓存最常用的查询，我们可以用它来解决此类问题。3.解析器和数据加载器如果我们可以看到后端访问的数据源的位置，那么我们可以更好地理解以下几个方面：我们是否在访问模式中使用了错误的数据源，或者需要使用其他类型如果数据源类型很好，我们需要改进请求它们的方式吗？我们需要添加数据加载器吗？这些对外部API的请求是否太慢？我们可以将数据复制到离后端更近的位置吗？可见，只有看到后端具体查询了哪些数据，才能解决上述问题。正如我们之前讨论的：解析器只允许我们监视单个解析器的操作；数据加载器允许我们在一个请求中查看所有解析器的工作。数据加载器的另一个好处是，我们能够发现解析器之间的问题并及时修复它们。4.fullstacktrace最全面彻底的监控方式是：使用tracing-ID标记查询，传递给解析器完成ID的解析，再传递给数据加载器，最终到达数据来源本身。据此，我们可以使用tracing-ID来记录时间和错误，方便后期合并，了解本地状态。当然，在测量查询时，我们得到的关于解析时间的数据实际上是数据被加载到解析器和/或数据加载器中，而不是完成查询解析的时间。毕竟，系统在加载数据时不再需要使用查询。这就是GraphQL的核心思想之一：将查询与实际数据的加载解耦。可以看出，通过全栈监控，我们可以充分了解发送查询时后台是如何工作的。结论综上所述，通过了解GraphQLAPI的后端结构，我们可以将RESTAPI挂接到目标代码中的不同位置，然后清晰全面地监控生产系统，了解缓存和错误处理等问题。原标题：HowtoBestMonitorGraphQLAPIs，作者：KayPloesser
