GraphQL在微服務(wù)架構(gòu)中實(shí)踐架構(gòu)

《GraphQL在微服務(wù)架構(gòu)中實(shí)踐架構(gòu)》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在工程資料-天天文庫(kù)。

1、GraphQL在微服務(wù)架構(gòu)中的實(shí)踐架構(gòu)目錄GraphQL是什么？iGraphQL在微服務(wù)架構(gòu)中的使用2GraphQL在實(shí)踐過(guò)程中遇到的棘手問(wèn)題3合理的GraphQL彳敦服務(wù)架構(gòu)的設(shè)計(jì)4一、GraphQL是什么？簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議（SOAP）從今天來(lái)看已經(jīng)是一門(mén)非常古老的Web服務(wù)技術(shù)了，雖然很多服務(wù)仍然在使用遵循SOAP的接口，但是到今天REST風(fēng)格的面向資源的API接口已經(jīng)非常深入人心,也非常的成熟；但是這篇文章要介紹的主角其實(shí)是另一門(mén)更加復(fù)雜、完備的查詢(xún)語(yǔ)言GraphQLo作為Facebook在2015年推出的查詢(xún)語(yǔ)言，GraphQL能夠?qū)PI中的數(shù)據(jù)提供一套易于理解

2、的完整描述,使得客戶(hù)端能夠更加準(zhǔn)確的獲得它需要的數(shù)據(jù)，目前包括Facebook.Twitter.GitHub在內(nèi)的很多公司都已經(jīng)在生產(chǎn)環(huán)境使用GraphQL提供API;其實(shí)無(wú)論我們是否決定生產(chǎn)環(huán)境中使用GraphQL,它確實(shí)是一門(mén)值得學(xué)習(xí)的技術(shù)。二、GraphQL在微服務(wù)架構(gòu)中的使用類(lèi)型系統(tǒng)GraphQL的強(qiáng)大表達(dá)能力主要還是來(lái)自于它完備的類(lèi)型系統(tǒng)，與REST不同，它將整個(gè)Web服務(wù)中的全部資源看成一個(gè)有連接的圖，而不是一個(gè)個(gè)資源孤島，在訪問(wèn)任何資源時(shí)都可以通過(guò)資源之間的連接訪問(wèn)其它的資源。GRAPHQUERYLANGUAGEIssue如上圖所示，當(dāng)我們?cè)L問(wèn)User資源時(shí)

3、，就可以通過(guò)GraphQL中的連接訪問(wèn)當(dāng)前User的Repo和Issue等資源，我們不再需要通過(guò)多個(gè)REST的接口分別獲取這些資源，只需要通過(guò)如下所示的查詢(xún)就能一次性拿到全部的結(jié)果：{user{idemailusernamerepos(first:10){idurlnameissues(first:20){idauthortitle}GraphQL這種方式能夠?qū)⒃蠷ESTful風(fēng)格時(shí)的多次請(qǐng)求聚合成一次請(qǐng)求，不僅能夠減少多次請(qǐng)求帶來(lái)的延遲，還能夠降低服務(wù)器壓力，加快前端的渲染速度。它的類(lèi)型系統(tǒng)也非常豐富，除了標(biāo)量、枚舉、列表和對(duì)象等類(lèi)型之外,還支持接口和聯(lián)合類(lèi)型等高級(jí)特

4、性。GRAPHQLSCHEMAInputUnionInterface為了能夠更好的表示非空和空字段，GraphQL也引入了NomNull等標(biāo)識(shí)代表非空的類(lèi)型，例如String!表示非空的字符串。schema{query:Querymutation:MutationSchema中絕大多數(shù)的類(lèi)型都是普通的對(duì)象類(lèi)型，但是每一個(gè)Schema中都有兩個(gè)特殊類(lèi)型：query和mutation,匕們是GraphQL中所有查詢(xún)的入口，在使用時(shí)所有查詢(xún)接口都是query的子字段，所有改變服務(wù)器資源的請(qǐng)求都應(yīng)該屬于mutation類(lèi)型。集中式vs分散式GraphQL以圖的形式將整個(gè)Web服務(wù)

5、中的資源展示出來(lái),其實(shí)我們可以理解為它將整個(gè)Web服務(wù)以〃SQL〃的方式展示給前端和客戶(hù)端，服務(wù)端的資源最終都被聚合到一張完整的圖上，這樣客戶(hù)端可以按照其需求自行調(diào)用,類(lèi)似添加字段的需求其實(shí)就不再需要后端多次修改了。與RESTful不同，每一個(gè)的GraphQL服務(wù)其實(shí)對(duì)外只提供了一個(gè)用于調(diào)用內(nèi)部接口的端點(diǎn),所有的請(qǐng)求都訪問(wèn)這個(gè)暴露出來(lái)的端點(diǎn)。GraphQLvsRESTful(endpoint)dravorwtt.”/叩1!/potttdr^venessGraphQL實(shí)際上將多個(gè)HTTP請(qǐng)求聚合成了一個(gè)請(qǐng)求，它只是將多個(gè)RESTful請(qǐng)求的資源變成了一個(gè)從根資源Post訪問(wèn)

6、其他資源的Comment和Author的圖,多個(gè)請(qǐng)求變成了一個(gè)請(qǐng)求的不同字段，從原有的分散式請(qǐng)求變成了集中式的請(qǐng)求，這種方式非常適合單體服務(wù)直接對(duì)外提供GraphQL服務(wù)，能夠在數(shù)據(jù)源和展示層建立一個(gè)非常清晰的分離，同時(shí)也能夠通過(guò)一些強(qiáng)大的工具，例如GraphiQL直接提供可視化的文檔;但是在業(yè)務(wù)復(fù)雜性指數(shù)提升的今天，微服務(wù)架構(gòu)成為了解決某些問(wèn)題時(shí)必不可少的解決方案，所以如何在微服務(wù)架構(gòu)中使用GraphQL提高前后端之間的溝通效率并降低開(kāi)發(fā)成本成為了一個(gè)值得考慮的問(wèn)題。Relay標(biāo)準(zhǔn)如果說(shuō)RESTful其實(shí)是客戶(hù)端與服務(wù)端在HTTP協(xié)議通信時(shí)定義的固定標(biāo)準(zhǔn)，那么Relay

7、其實(shí)也是我們?cè)谑褂肎raphQL可以遵循的一套規(guī)范。GRAPHQLANDRELAY這種標(biāo)準(zhǔn)的出現(xiàn)能夠讓不同的工程師開(kāi)發(fā)出較為相似的通信接口，在一些場(chǎng)景下，例如標(biāo)識(shí)對(duì)象和分頁(yè)這種常見(jiàn)的需求，引入設(shè)計(jì)良好的標(biāo)準(zhǔn)能夠降低開(kāi)發(fā)人員之間的溝通成本。Relay標(biāo)準(zhǔn)其實(shí)為三個(gè)與API有關(guān)的最常見(jiàn)的問(wèn)題制定了一些規(guī)范:提供能夠重新獲取對(duì)象的機(jī)制;提供對(duì)^何對(duì)連接進(jìn)行分頁(yè)的描述;標(biāo)準(zhǔn)化mutation請(qǐng)求，使它們變得更加可預(yù)測(cè)；通過(guò)將上述的三個(gè)問(wèn)題規(guī)范化，能夠極大地增加前后端對(duì)于接口制定和對(duì)接時(shí)的工作效率。對(duì)象標(biāo)識(shí)符Node是Relay標(biāo)準(zhǔn)中定