偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

如何對(duì)GraphQL APIs實(shí)現(xiàn)監(jiān)控

譯文
安全 應(yīng)用安全
在實(shí)際應(yīng)用中,我們往往會(huì)疑惑:如何使用GraphQL來準(zhǔn)確地監(jiān)控到目標(biāo)系統(tǒng)的重要位置。本文將和您一起討論那些有關(guān)GraphQL APIs監(jiān)控的優(yōu)秀實(shí)踐。

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

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

[[331112]]

GraphQL架構(gòu)

為了弄清楚上述問題件,讓我們首先來了解GraphQL的架構(gòu)。通常,一個(gè)簡單的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ù)器了解到哪種解析器能夠處理哪種類型的查詢。也就是說,當(dāng)一個(gè)查詢被發(fā)送到GraphQL端點(diǎn)時(shí),GraphQL引擎會(huì)解析該查詢中的每一種請(qǐng)求類型,進(jìn)而調(diào)用解析器來滿足其請(qǐng)求??梢韵胂?,此類方法僅限于在與簡單查詢一起使用時(shí),才能提供卓越的性能。

有時(shí)候,查詢的某些部分會(huì)被連接到同一個(gè)數(shù)據(jù)源(包括數(shù)據(jù)庫或第三方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層。通過簡單的設(shè)置,解析器將能夠直接訪問到數(shù)據(jù)源。而在更為復(fù)雜的迭代中,解析器則會(huì)告訴數(shù)據(jù)加載器它們到底需要什么,據(jù)此加載器也會(huì)針對(duì)該目的去訪問數(shù)據(jù)源。

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

可見,解析器只需了解其對(duì)應(yīng)的需求,而數(shù)據(jù)加載器則需要知道所有解析器的目的,并據(jù)此來優(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ò)誤率的全量信息,而且客戶端并無任何投訴產(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)因素。由于持久化查詢(Persisted queries,https://blog.apollographql.com/persisted-graphql-queries-with-apollo-client-119fd7e6bba5)可以緩存那些最常用的查詢,因此我們可以用它來解決此類問題。

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

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

  • 是在訪問模式中使用了錯(cuò)誤的數(shù)據(jù)源,還是需要改用其他類型的數(shù)據(jù)庫?
  • 如果數(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來標(biāo)記查詢,將其傳遞給解析器以完成對(duì)該ID的解析,然后傳遞給數(shù)據(jù)加載器,并最終抵達(dá)數(shù)據(jù)源本身。據(jù)此,我們可以使用tracing-ID來記錄時(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é)論

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

原標(biāo)題:How to Best Monitor GraphQL APIs ,作者: Kay Ploesser 

【51CTO譯稿,合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】

責(zé)任編輯:趙寧寧 來源: 51CTO
相關(guān)推薦

2016-08-05 15:04:33

javascripthtmljs

2023-06-08 09:44:13

WindowSpy目標(biāo)用戶監(jiān)控

2023-11-09 09:13:48

GraphQLAPI 架構(gòu)

2010-10-12 16:26:44

2020-10-27 18:45:45

GolangGraphQ開發(fā)

2021-06-03 09:00:00

Kubernetes集群容器

2018-04-23 14:31:02

微服務(wù)GraphQLBFF

2023-03-10 15:03:37

Web 應(yīng)用程序API開發(fā)

2021-05-07 09:06:55

GraphQLAPI 以太坊

2023-03-16 18:04:00

APIWeb 應(yīng)用程序開發(fā)

2009-07-02 10:03:02

DataView排序

2016-10-20 09:07:51

ChromiumGoogleEloston

2020-03-09 09:15:56

集群Prometheus開源

2019-07-07 08:02:05

AI人工智能智能監(jiān)控

2014-05-21 09:14:00

VDI審計(jì)日志監(jiān)控監(jiān)控

2014-05-21 14:03:55

日志監(jiān)控VDI

2014-01-02 15:16:42

PythonLinux服務(wù)器服務(wù)器監(jiān)控

2011-03-31 14:44:55

cactisquid監(jiān)控

2020-09-28 06:57:39

Node.jsGraphQLAPI

2022-12-05 13:45:06

Actuator監(jiān)控
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)