作為REST的另一種選擇，GraphQL自2015年發(fā)布以來，為前端開發(fā)人員提供了他們渴望已久的靈活性。他們可以通過一次性查詢，來定義所有需要的數(shù)據(jù)，并能夠一次性地“打包”獲取，進而大幅減少了等待的時間。

除了簡化前端，REST也讓監(jiān)控等方面變得更加簡單。據(jù)此，后端團隊可以考量每一個端點的狀態(tài)，并能夠及時地發(fā)現(xiàn)當前出現(xiàn)的問題。當然，在使用的過程中，我們需要考慮清楚的最關(guān)鍵問題是：如何使用GraphQL來準確地監(jiān)控到目標系統(tǒng)的重要位置。下面，讓我們一起來討論那些有關(guān)GraphQL APIs監(jiān)控的優(yōu)秀實踐。

GraphQL架構(gòu)

為了弄清楚上述問題件，讓我們首先來了解GraphQL的架構(gòu)。通常，一個簡單的GraphQL系統(tǒng)會包括如下三個部分：

一種可定義所有數(shù)據(jù)類型的schema（結(jié)構(gòu)模式）。

一個使用該schema將查詢到的每個部分都路由到某個解析器（resolver）的GraphQL引擎。

一到多個能夠被GraphQL引擎所調(diào)用的解析器。

通過解析schema，GraphQL后端會讓服務(wù)器了解到哪種解析器能夠處理哪種類型的查詢。也就是說，當一個查詢被發(fā)送到GraphQL端點時，GraphQL引擎會解析該查詢中的每一種請求類型，進而調(diào)用解析器來滿足其請求?？梢韵胂螅祟惙椒▋H限于在與簡單查詢一起使用時，才能提供卓越的性能。

有時候，查詢的某些部分會被連接到同一個數(shù)據(jù)源（包括數(shù)據(jù)庫或第三方API等）。例如，如果我們加載某個用戶的賬號及其地址，它們可能在GraphQL的schema中具有兩種類型，而在數(shù)據(jù)源中卻只有一條記錄。那么我們同時發(fā)出請求的時候，當然不希望服務(wù)器對同一個數(shù)據(jù)源發(fā)出兩次查詢請求。

針對上述問題，業(yè)界會采用一種被稱為數(shù)據(jù)加載器（data-loader）的模式。該數(shù)據(jù)加載器是位于解析器和數(shù)據(jù)源之間的另一個GraphQL API層。通過簡單的設(shè)置，解析器將能夠直接訪問到數(shù)據(jù)源。而在更為復(fù)雜的迭代中，解析器則會告訴數(shù)據(jù)加載器它們到底需要什么，據(jù)此加載器也會針對該目的去訪問數(shù)據(jù)源。

那么，由此帶來的好處是：數(shù)據(jù)加載器可以持續(xù)等待，直到所有的解析器都已被調(diào)用，并且完成了對于數(shù)據(jù)源的訪問為止。針對上面提到的例子，如果有人想加載用戶的賬號和地址的話，那么只需對數(shù)據(jù)源發(fā)出一個請求便可。

可見，解析器只需了解其對應(yīng)的需求，而數(shù)據(jù)加載器則需要知道所有解析器的目的，并據(jù)此來優(yōu)化具體的訪問。

監(jiān)控GraphQL

有了上面的理論基礎(chǔ)，我們就可以根據(jù)自己的架構(gòu)，在如下多個位置監(jiān)控GraphQL API了：

HTTP端點：針對那些影響到我們API的所有流量。

GraphQL查詢：針對每個特定的查詢。

GraphQL解析器或數(shù)據(jù)加載器：針對數(shù)據(jù)源的每個訪問。

全棧追蹤：針對每個查詢所影響到的解析器和數(shù)據(jù)加載器。

1. HTTP端點

在GraphQL架構(gòu)中，通常只有一個HTTP端點，因此在該REST API級別上的監(jiān)控，往往只能讓我們了解到有關(guān)API總體狀態(tài)的信息。

當然，這只是我們監(jiān)控的一個起點。如果能夠提供低延遲、低錯誤率的全量信息，而且客戶端并無任何投訴產(chǎn)生的話，那么這些指標完全可以為我們節(jié)約后續(xù)花在深度監(jiān)控上的大量時間和精力。但是，如果某個地方出現(xiàn)了問題，我們就需要更深入地進行探究了。

2. GraphQL查詢

下面，我們需要監(jiān)控每一個查詢，當然主要針對的是那些靜態(tài)使用模式（static usage patterns）的API。

如果我們僅將API與自己的客戶端一起使用的話，那么針對固有查詢的變化一般不會經(jīng)常發(fā)生。而如果我們的API需要處理不同客戶端的不同請求，那么查詢請求不但多，而且雜。這些只有細微差別的請求往往會拖慢整體的速度。而消除此類問題的一種做法是：檢查那些最常見的查詢，并對它們實施綜合監(jiān)控。這就意味著我們需要事先定義一整套查詢和變量的組合，然后從測試客戶端運行之，以獲悉它們的用時。在此基礎(chǔ)上，我們能夠減少在更新時產(chǎn)生的，嚴重影響性能的風險因素。由于持久化查詢可以緩存那些最常用的查詢，因此我們可以用它來解決此類問題。

3. 解析器和數(shù)據(jù)加載器

如果我們能夠查看到后端所訪問的數(shù)據(jù)源位置，那么就能夠更好地獲悉如下方面：

是在訪問模式中使用了錯誤的數(shù)據(jù)源，還是需要改用其他類型的數(shù)據(jù)庫？

如果數(shù)據(jù)源類型沒問題的話，那么我們還需要改進對它們的請求方式嗎？我們是否需要添加數(shù)據(jù)加載器？

那些發(fā)送到外部API的請求是否太慢了？我們是否可以將數(shù)據(jù)復(fù)制到更接近后端的位置？

可見，只有當我們能夠看到后端具體查詢的是什么數(shù)據(jù)時，上述問題的答案才能迎刃而解。

正如我們在前面討論過的：解析器只能允許我們監(jiān)控單個解析器的運作;而數(shù)據(jù)加載器使我們能夠在一個請求中查看到所有解析器的工作。那么，數(shù)據(jù)加載器的另一個附帶好處便是：我們能夠發(fā)現(xiàn)解析器之間的問題，并及時予以解決。

4. 全棧跟蹤

最為全面透徹的監(jiān)控方式當屬：使用tracing-ID來標記查詢，將其傳遞給解析器以完成對該ID的解析，然后傳遞給數(shù)據(jù)加載器，并最終抵達數(shù)據(jù)源本身。據(jù)此，我們可以使用tracing-ID來記錄時間和錯誤，以便后續(xù)對其進行合并，以及了解局部狀態(tài)。

當然，在測量查詢時，我們所獲取到的有關(guān)解析用時的數(shù)據(jù)，實際上是數(shù)據(jù)被加載到解析器和/或數(shù)據(jù)加載器中進行的，而不是完成查詢解析的用時。畢竟，系統(tǒng)在加載數(shù)據(jù)時，已不再需要使用查詢了。這也就是GraphQL的核心思想之一：將查詢與實際數(shù)據(jù)的加載進行解耦（decoupling）。可見，我們通過全棧監(jiān)控，可以全面地獲悉在發(fā)送查詢時，后臺究竟是如何運作的。

結(jié)論

總的說來，通過了解GraphQL API的后端結(jié)構(gòu)，我們可以將REST API掛接到目標代碼的不同位置，進而清晰且全面地監(jiān)控生產(chǎn)系統(tǒng)，以獲悉有關(guān)緩存和錯誤處理等方面的問題。