概述

隨著業(yè)務(wù)的不斷擴(kuò)張，各種運(yùn)營(yíng)活動(dòng)越來(lái)越多，原有的前端渲染-后端提供業(yè)務(wù)接口的開發(fā)方式對(duì)于一個(gè)生命周期可能只有幾天的活動(dòng)來(lái)說(shuō)成本巨大。閑魚在降低開發(fā)成本，提高整體效率上做了一些嘗試和實(shí)踐。本文介紹閑魚從數(shù)據(jù)聚合方面進(jìn)行了一些探索和嘗試，以及Graphql的引入給閑魚帶了研發(fā)效率的提升。

背景

長(zhǎng)期以來(lái)，前端和后端開發(fā)中面臨一個(gè)矛盾：前端希望頁(yè)面只獲取結(jié)構(gòu)化數(shù)據(jù)，能夠直接渲染出頁(yè)面組件;后端則希望只提供業(yè)務(wù)領(lǐng)域API服務(wù)能力，數(shù)據(jù)組裝和處理由前端完成。mock數(shù)據(jù)，聯(lián)調(diào)等低價(jià)值的工作會(huì)耗費(fèi)很多的成本，原有的開發(fā)模式已跟不上業(yè)務(wù)快速發(fā)展的節(jié)奏。 因此我們希望前端可以直接獲取數(shù)據(jù)，后端又能從重復(fù)的、低價(jià)值的消費(fèi)型開發(fā)中解放出來(lái)。 

數(shù)據(jù)聚合是我們解決的一個(gè)思路。

1. 數(shù)據(jù)聚合的解決方案

數(shù)據(jù)聚合是將多個(gè)服務(wù)請(qǐng)求一起打包給服務(wù)端，服務(wù)端一次性返回相應(yīng)請(qǐng)求的結(jié)果，這種方式可以降低網(wǎng)絡(luò)耗時(shí)，在數(shù)據(jù)處理上也會(huì)更方便。在入?yún)⒄Z(yǔ)法上也有擴(kuò)展的可能性，比如依賴調(diào)用等，是一種比RESTFul更加靈活和高效的查詢方式。 

在數(shù)據(jù)聚合的調(diào)用下，由于服務(wù)端的業(yè)務(wù)領(lǐng)域接口已經(jīng)存在，這些接口認(rèn)為是可靠的，聯(lián)調(diào)成本將會(huì)大大降低，在一些測(cè)試環(huán)境發(fā)生異常的情形，前端甚至可以直接在線上測(cè)試。

設(shè)計(jì)原則

• 服務(wù)端暴露通用場(chǎng)景的數(shù)據(jù)服務(wù)，即標(biāo)準(zhǔn)業(yè)務(wù)API，包括數(shù)據(jù)查詢和寫入;
• 盡可能少與前端交互，一次調(diào)用獲取所有所需數(shù)據(jù)
• 并發(fā)/異步調(diào)用降低耗時(shí)

2. 數(shù)據(jù)聚合1.0

閑魚服務(wù)端開發(fā)了第一個(gè)數(shù)據(jù)聚合服務(wù)。 通過(guò)將底層服務(wù)暴露出來(lái)，從請(qǐng)求總?cè)肟谶M(jìn)行并發(fā)調(diào)用具體的服務(wù)接口，頁(yè)面多個(gè)服務(wù)查詢可以一次性將所有的數(shù)據(jù)返回給前端。 調(diào)用過(guò)程如下： 

這個(gè)框架有如下幾個(gè)特點(diǎn):

• 非常輕量，核心代碼1000行左右
• 去中心化直接部署在應(yīng)用系統(tǒng)上，不依賴其他二方包和服務(wù)系統(tǒng)，
• 無(wú)代碼入侵，無(wú)需對(duì)現(xiàn)有系統(tǒng)服務(wù)和代碼做改造適配，僅需在注冊(cè)中心注冊(cè)服務(wù)即可

全并發(fā)調(diào)用，調(diào)用的多個(gè)服務(wù)API均采用并發(fā)方式調(diào)用，耗時(shí)低 此外我們對(duì)其語(yǔ)法結(jié)構(gòu)和功能上進(jìn)行了擴(kuò)展：支持字段選取，依賴調(diào)用，循環(huán)依賴檢查，別名等功能： 

2.1 上線效果

上線半年內(nèi)，數(shù)據(jù)聚合服務(wù)支撐了30+的頁(yè)面上線，占同類需求的80%以上，降低了兩端的開發(fā)成本超過(guò)50%。

2.2 閑魚聚合服務(wù)上線后存在以下問(wèn)題：

數(shù)據(jù)響應(yīng)結(jié)構(gòu)對(duì)調(diào)用方不夠友好，雖然支持依賴調(diào)用，但是返回的數(shù)據(jù)是平級(jí)展現(xiàn)形式，對(duì)于一些批量接口來(lái)說(shuō)，返回的結(jié)構(gòu)往往是Map結(jié)構(gòu)，這需要調(diào)用方進(jìn)一步處理，增加了復(fù)雜度;

安全性問(wèn)題。multiquery的查詢串沒(méi)有經(jīng)過(guò)加密，一些非法的請(qǐng)求可能會(huì)修改查詢語(yǔ)句帶來(lái)系統(tǒng)風(fēng)險(xiǎn);而且對(duì)于一些敏感數(shù)據(jù)需要加密或脫敏處理，multiquery語(yǔ)法結(jié)構(gòu)上缺乏數(shù)據(jù)處理的擴(kuò)展點(diǎn)

研發(fā)體系不完善：缺乏對(duì)服務(wù)的meta信息透出，導(dǎo)致調(diào)用方不清楚要用哪個(gè)服務(wù)，入?yún)⑹鞘裁闯鰠⑹鞘裁矗p方存在一定的溝通成本。沒(méi)有ide支撐，書寫起來(lái)比較困難。

3. GraphQL-像寫sql一樣拼裝數(shù)據(jù)

3.1 什么是Graphql

Graphql (https://graphql.org ) 是 facebook 推出的一種數(shù)據(jù)查詢語(yǔ)言，其設(shè)計(jì)的目的是要將不穩(wěn)定的數(shù)據(jù)組裝部分從穩(wěn)定的業(yè)務(wù)數(shù)據(jù)邏輯中剝離，使數(shù)據(jù)控制邏輯前移，開發(fā)模式由“下發(fā)數(shù)據(jù)”轉(zhuǎn)變成“取數(shù)據(jù)”的過(guò)程。 

Graphql的優(yōu)勢(shì)：

結(jié)構(gòu)化清晰：所見即所得，輸入和輸出結(jié)構(gòu)一致，前端需要什么數(shù)據(jù)字段，就在ql上填寫什么字段，同時(shí)支持多層級(jí)結(jié)構(gòu)，也可以平級(jí)展現(xiàn)，由調(diào)用方根據(jù)業(yè)務(wù)決定合適的輸出形式。

精細(xì)化場(chǎng)景控制：即便是類似的場(chǎng)景，需要的數(shù)據(jù)也可能不完全相同，graphql中沒(méi)有一個(gè)數(shù)據(jù)是多余的

數(shù)據(jù)處理可擴(kuò)展性強(qiáng)：graphql提供了很多Directives滿足日常的開發(fā)需求，甚至支持js代碼, 開發(fā)者也可以自定義一套工具庫(kù)來(lái)擴(kuò)展

3.2 GraphQL接入應(yīng)用改造

閑魚選擇了TQL作為Graphql的服務(wù)端實(shí)現(xiàn)。Tql是淘寶提供的對(duì)GraphQL的java實(shí)現(xiàn)，并解決了開源版graphql的很多局限性和痛點(diǎn)，提供了很多特性，使graphql能夠低成本部署在應(yīng)用上。

接入簡(jiǎn)單，代碼侵入性低：去中心化的設(shè)計(jì)，不依賴二方服務(wù)，應(yīng)用系統(tǒng)直接引入可用

研發(fā)體系支撐：提供了ql編寫的在線ide，可展示各個(gè)服務(wù)的meta信息,提高了開發(fā)效率，書寫提示，執(zhí)行耗時(shí)日志，調(diào)用場(chǎng)景監(jiān)控等功能便于服務(wù)性能優(yōu)化

多執(zhí)行策略：提供了并發(fā)執(zhí)行策略和異步執(zhí)行策略，在多服務(wù)調(diào)用和層級(jí)調(diào)用場(chǎng)景上保證了ql的高效運(yùn)行;

合并調(diào)用：執(zhí)行前合并所依賴的上游數(shù)據(jù)集中的元素，這樣我們就可以充分利用批量接口查詢，而不是單個(gè)多次調(diào)用，性能顯著提高

安全性提升： graphql語(yǔ)句從前端請(qǐng)求到服務(wù)端,用簽名的方式來(lái)避免查詢串被篡改

3.2.1服務(wù)端改造

• 統(tǒng)一graphql查詢接口
• 原有的一個(gè)業(yè)務(wù)領(lǐng)域服務(wù)再包裝一個(gè)GraphQL的Function

Function入?yún)⒏脑欤?/strong> 后臺(tái)的服務(wù)參數(shù)對(duì)于前端視角可能不同(參數(shù)過(guò)多，影響數(shù)據(jù)的參數(shù)等)

非批量Function出參：一般無(wú)需改造，同上

支持批量的Function改造，返回結(jié)構(gòu)必須是有序List

非標(biāo)準(zhǔn)DO參數(shù)：由于輸出是JSON，存在循環(huán)依賴的java對(duì)象使用fastjson輸出時(shí)會(huì)造成棧溢出

開發(fā)GraphQL API

下面的示例可以提供一個(gè)Graphql的API。@GraphQLDataFetcher 注解表示該方法可以作為Graphql的數(shù)據(jù)源，supportBatch = true表示支持合并調(diào)用，執(zhí)行前會(huì)將依賴的數(shù)據(jù)結(jié)果合并成一個(gè)List作為入?yún)?

支持合并調(diào)用情況下要求我們保證兩點(diǎn)：

• 入?yún)serids的長(zhǎng)度和返回的List長(zhǎng)度一致，否則無(wú)法回填到相應(yīng)的字段上;
• 返回的數(shù)據(jù)順序要和入?yún)⒌捻樞驅(qū)?yīng)，否則會(huì)造成數(shù)據(jù)錯(cuò)誤。

統(tǒng)一graphql Gateway API

執(zhí)行時(shí)會(huì)自動(dòng)引入當(dāng)前請(qǐng)求的全局信息，如登錄用戶，設(shè)備id,設(shè)備機(jī)型等，如UserAgent可獲取用戶的機(jī)型，系統(tǒng)等信息，不需要前端和后端額外處理，可以直接使用。

3.2.2前端調(diào)用改造

• 調(diào)用接口改為后端提供的統(tǒng)一graphql接口
• 根據(jù)業(yè)務(wù)需求使用graphql語(yǔ)法表達(dá)所需數(shù)據(jù)

調(diào)用graphql gateway API:

編寫GraphQL 查詢語(yǔ)句，獲取結(jié)構(gòu)化數(shù)據(jù)： 

隨著前端團(tuán)隊(duì)增多和人員流動(dòng)，我們對(duì)Graphql的學(xué)習(xí)成本，ql復(fù)用以及管理上提出了更高的要求。

4. GraphqlQL管理平臺(tái)

管理平臺(tái)給開發(fā)者提供了很多便利。在線編編輯ql和保存，在線調(diào)試，即時(shí)發(fā)布，多人可見，有示例參考，降低了graphql的學(xué)習(xí)成本。 

前端在頁(yè)面請(qǐng)求時(shí)只需要傳入對(duì)應(yīng)的Id,不再需要graphql查詢語(yǔ)句

GraphQL給閑魚帶來(lái)的變化

研發(fā)成本降低

引入Graphql后兩端的研發(fā)成本顯著降低，運(yùn)營(yíng)類場(chǎng)景整體上線時(shí)間明顯縮短，大部分情況下，服務(wù)端的成本為0。而前端在編寫graphql語(yǔ)句+自測(cè)的時(shí)間可能只有10分鐘。 

GraphqlQL可以與前端頁(yè)面搭建平臺(tái)完美結(jié)合，如TMS,已經(jīng)有很多頁(yè)面組件是基于GraphqlQL來(lái)完成的.借助graphql可以很方便地構(gòu)建出各種各樣的頁(yè)面組件，對(duì)研發(fā)無(wú)人化的方向上也有積極作用。

耗時(shí)

通過(guò)分析graphql的執(zhí)行日志，主要耗時(shí)在實(shí)際調(diào)用的接口耗時(shí)，graphql自身的耗時(shí)一般在20ms以下，某些情況下耗時(shí)較長(zhǎng)。graphql耗時(shí)點(diǎn)包括：

• ql復(fù)雜度
• @js指令 后端執(zhí)行js腳本會(huì)引起較多耗時(shí)增加
• 合并調(diào)用時(shí)的入?yún)?shù)據(jù)處理與回填也有一定影響

5. 總結(jié)

本文介紹了閑魚在數(shù)據(jù)聚合上的一些探索和嘗試,并介紹了Graphql的引入和應(yīng)用改造。從自研服務(wù)到Graphql的引入，研發(fā)效率不斷提升,并取得了很好的效果。 目前，graphql還只在weex/h5的場(chǎng)景上使用，將來(lái)我們會(huì)在native上使用并逐步擴(kuò)大。

GraphqlQL的引入使前端/客戶端和服務(wù)端的編程模式發(fā)生了很大的改變。

• 服務(wù)端從此只需專注于建設(shè)穩(wěn)定的業(yè)務(wù)領(lǐng)域模型，不再維護(hù)不穩(wěn)定的、容易變化的VO層，也不需要與前端反復(fù)溝通結(jié)構(gòu)定義。
• 前端/客戶端 不再依賴服務(wù)端特定的接口，而是通過(guò) graphql 來(lái)自由組合服務(wù)端提供各種數(shù)據(jù)服務(wù)，也可以更方便的進(jìn)行頁(yè)面搭建，服務(wù)端基本不需要參與。
• 前端/客戶端 對(duì)業(yè)務(wù)模型也會(huì)有更深入的理解。