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

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

GraphQL架構(gòu)

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

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

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

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

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

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

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

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

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

監(jiān)控GraphQL

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

HTTP端點(diǎn)：針對(duì)那些影響到我們API的所有流量。

GraphQL查詢：針對(duì)每個(gè)特定的查詢。

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

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

1. HTTP端點(diǎn)

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

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

2. GraphQL查詢

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

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

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

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

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

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

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

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

正如我們?cè)谇懊嬗懻撨^的：解析器只能允許我們監(jiān)控單個(gè)解析器的運(yùn)作;而數(shù)據(jù)加載器使我們能夠在一個(gè)請(qǐng)求中查看到所有解析器的工作。那么，數(shù)據(jù)加載器的另一個(gè)附帶好處便是：我們能夠發(fā)現(xiàn)解析器之間的問題，并及時(shí)予以解決。

4. 全棧跟蹤

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

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

結(jié)論

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