概述

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

背景

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

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

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

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

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

設(shè)計原則

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

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

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

這個框架有如下幾個特點:

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

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

2.1 上線效果

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

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

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

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

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

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

3.1 什么是Graphql

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

Graphql的優(yōu)勢：

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

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

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

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

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

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

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

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

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

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

3.2.1服務(wù)端改造

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

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

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

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

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

開發(fā)GraphQL API

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

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

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

統(tǒng)一graphql Gateway API

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

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

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

調(diào)用graphql gateway API:

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

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

4. GraphqlQL管理平臺

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

前端在頁面請求時只需要傳入對應(yīng)的Id,不再需要graphql查詢語句

GraphQL給閑魚帶來的變化

研發(fā)成本降低

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

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

耗時

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

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

5. 總結(jié)

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

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

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