閑魚在數據聚合上的探索與實踐

概述

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

背景

長期以來，前端和后端開發中面臨一個矛盾：前端希望頁面只獲取結構化數據，能夠直接渲染出頁面組件；后端則希望只提供業務領域API服務能力，數據組裝和處理由前端完成。mock數據，聯調等低價值的工作會耗費很多的成本，原有的開發模式已跟不上業務快速發展的節奏。 因此我們希望前端可以直接獲取數據，后端又能從重復的、低價值的消費型開發中解放出來。

數據聚合是我們解決的一個思路。

1. 數據聚合的解決方案

數據聚合是將多個服務請求一起打包給服務端，服務端一次性返回相應請求的結果，這種方式可以降低網絡耗時，在數據處理上也會更方便。在入參語法上也有擴展的可能性，比如依賴調用等，是一種比RESTFul更加靈活和高效的查詢方式。

在數據聚合的調用下，由于服務端的業務領域接口已經存在，這些接口認為是可靠的，聯調成本將會大大降低，在一些測試環境發生異常的情形，前端甚至可以直接在線上測試。

設計原則

• 服務端暴露通用場景的數據服務，即標準業務API，包括數據查詢和寫入;

• 盡可能少與前端交互，一次調用獲取所有所需數據

• 并發/異步調用降低耗時

2. 數據聚合1.0

閑魚服務端開發了第一個數據聚合服務。 通過將底層服務暴露出來，從請求總入口進行并發調用具體的服務接口，頁面多個服務查詢可以一次性將所有的數據返回給前端。 調用過程如下：

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

• 非常輕量，核心代碼1000行左右

• 去中心化直接部署在應用系統上，不依賴其他二方包和服務系統，

• 無代碼入侵，無需對現有系統服務和代碼做改造適配，僅需在注冊中心注冊服務即可

• 全并發調用，調用的多個服務API均采用并發方式調用，耗時低 此外我們對其語法結構和功能上進行了擴展：支持字段選取，依賴調用，循環依賴檢查，別名等功能：

2.1 上線效果

上線半年內，數據聚合服務支撐了30+的頁面上線，占同類需求的80%以上，降低了兩端的開發成本超過50%。

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

• 數據響應結構對調用方不夠友好，雖然支持依賴調用，但是返回的數據是平級展現形式，對于一些批量接口來說，返回的結構往往是Map結構，這需要調用方進一步處理，增加了復雜度；

• 安全性問題。multiquery的查詢串沒有經過加密，一些非法的請求可能會修改查詢語句帶來系統風險；而且對于一些敏感數據需要加密或脫敏處理，multiquery語法結構上缺乏數據處理的擴展點

• 研發體系不完善：缺乏對服務的meta信息透出，導致調用方不清楚要用哪個服務，入參是什么出參是什么，雙方存在一定的溝通成本。沒有ide支撐，書寫起來比較困難。

3. GraphQL-像寫sql一樣拼裝數據

3.1 什么是Graphql

Graphql (https://graphql.org ) 是 非死book 推出的一種數據查詢語言，其設計的目的是要將不穩定的數據組裝部分從穩定的業務數據邏輯中剝離，使數據控制邏輯前移，開發模式由“下發數據”轉變成“取數據”的過程。

Graphql的優勢：

• 結構化清晰：所見即所得，輸入和輸出結構一致，前端需要什么數據字段，就在ql上填寫什么字段，同時支持多層級結構，也可以平級展現，由調用方根據業務決定合適的輸出形式。

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

• 數據處理可擴展性強：graphql提供了很多Directives滿足日常的開發需求，甚至支持js代碼, 開發者也可以自定義一套工具庫來擴展

3.2 GraphQL接入應用改造

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

• 接入簡單，代碼侵入性低：去中心化的設計，不依賴二方服務，應用系統直接引入可用

• 研發體系支撐：提供了ql編寫的在線ide，可展示各個服務的meta信息,提高了開發效率，書寫提示，執行耗時日志，調用場景監控等功能便于服務性能優化

• 多執行策略：提供了并發執行策略和異步執行策略，在多服務調用和層級調用場景上保證了ql的高效運行；

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

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

3.2.1服務端改造

• 統一graphql查詢接口

• 原有的一個業務領域服務再包裝一個GraphQL的Function

Function入參改造： 后臺的服務參數對于前端視角可能不同（參數過多，影響數據的參數等） 

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

支持批量的Function改造，返回結構必須是有序List 

非標準DO參數：由于輸出是JSON，存在循環依賴的java對象使用fastjson輸出時會造成棧溢出

開發GraphQL API

下面的示例可以提供一個Graphql的API。@GraphQLDataFetcher 注解表示該方法可以作為Graphql的數據源，supportBatch = true表示支持合并調用，執行前會將依賴的數據結果合并成一個List作為入參；

支持合并調用情況下要求我們保證兩點：

• 入參userids的長度和返回的List長度一致，否則無法回填到相應的字段上；

• 返回的數據順序要和入參的順序對應，否則會造成數據錯誤。

統一graphql Gateway API

執行時會自動引入當前請求的全局信息，如登錄用戶，設備id,設備機型等，如UserAgent可獲取用戶的機型，系統等信息，不需要前端和后端額外處理，可以直接使用。

3.2.2前端調用改造

• 調用接口改為后端提供的統一graphql接口

• 根據業務需求使用graphql語法表達所需數據 

調用graphql gateway API:

編寫GraphQL 查詢語句，獲取結構化數據：

隨著前端團隊增多和人員流動，我們對Graphql的學習成本，ql復用以及管理上提出了更高的要求。

4. GraphqlQL管理平臺

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

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

GraphQL給閑魚帶來的變化

研發成本降低

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

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

耗時

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

• ql復雜度

• @js指令 后端執行js腳本會引起較多耗時增加

• 合并調用時的入參數據處理與回填也有一定影響

5. 總結

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

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

• 服務端從此只需專注于建設穩定的業務領域模型，不再維護不穩定的、容易變化的VO層，也不需要與前端反復溝通結構定義。

• 前端/客戶端 不再依賴服務端特定的接口，而是通過 graphql 來自由組合服務端提供各種數據服務，也可以更方便的進行頁面搭建，服務端基本不需要參與。

• 前端/客戶端 對業務模型也會有更深入的理解。

 

來自：https://mp.weixin.qq.com/s/9P_16cNEF0puHg75fVL1xA