背景
極光目前業務線較多，各個業務線都有資料服務API的開發需求，過去公司沒有統一的資料服務匯流排，導致資料來源重複開發、資料應用API重複開發現象較多，資源浪費嚴重，資料服務平臺主要旨在：
提供統一的對內對外的資料API介面，規範資料服務API的開發與管理
結合資料地圖，打通資料應用和資料工程，實現資料價值和鏈路血緣的補充
一、極光資料服務平臺介紹
極光資料服務平臺提供將資料表生成API的能力，支援視覺化嚮導模式或指令碼模式快速開發API介面，支援關係型資料庫和NoSQL資料庫，可供內部和外部系統通過呼叫API介面獲取資料，對開放的API進行統一管理和釋出。
【核心功能】：
【視覺化API開發】提供視覺化開發API功能，即可快速配置一個API，提高交付效率
【視覺化API除錯】提供最基本的視覺化的API除錯功能，減少測試成本
【統一的API管理】提供統一的各業務線對內對外的API管理功能
【API監控告警】提供介面呼叫統計視覺化報表、監控、告警等功能
【API市場】平臺配置的API統一發布到API市場，各業務的資料開發/產品經理們可檢視API市場釋出的API是否可為自身業務創造價值，可根據業務需要申請使用
【使用物件】：
資料開發：配置資料來源、配置API介面，用於產品介面/業務介面快速開發
資料服務平臺開發：管理業務介面、管理資料來源、平臺穩定性保障
產品運營：業務介面監控、產品介面使用情況資料分析
1.1 使用流程
API釋出者流程：
圖1-1-1
API使用者流程：
圖1-1-2
1.2 資料來源管理
資料服務平臺提供資料來源管理功能，資料開發工程將開發好的資料表登記到此平臺，業務部門只能管理各自的資料來源。
圖1-2-1
一期資料來源只支援pika和redis元件，後續會支援更多儲存元件（hbase/mysql/es等）
1.3 API開發
有了資料來源後，業務開發就可以基於該資料來源配置API介面入參和出參等資訊，快速生成和釋出API，提高業務交付效率。
圖1-3-1
通過資料服務開發的API，能規範API介面定義，統一管理各業務線的API介面。
1.4 API除錯
配置API完成後，就進入到API調式階段，在這裡業務開發可以輸入請求引數的值進行呼叫，檢視請求詳情和返回內容，驗證API介面入參與出參是否符合預期。
圖1-4-1
1.5 API釋出
API除錯通過後，就可以釋出API，這裡需要走工單審批，審批通過後，會自動釋出的API閘道器。
1.6 API閘道器
作為資料服務API閘道器，必須具備身份認證、許可權驗證、限頻限流等功能。
身份認證：為了解決介面安全問題，會為每個產品線分配一對devKey和devSecret，API介面在呼叫時，需要帶上devKey和簽名資訊才能訪問。
許可權驗證：對於每個已釋出的API，都要經過API負責人授權才能訪問。
限頻限流：API負責人在釋出API時，可以設定介面的QPS和QPD，超過設定的閾值，就會限制介面的訪問。
1.7 API市場
API釋出成功後，會上架到API市場，業務開發可以在API市場搜尋和檢視已經上架的API介面的入參、出參、錯誤碼、釋出者等資訊，還能申請某些API的許可權，審批通過後就可以直接呼叫該API介面獲取資料。
圖1-7-1
圖1-7-2
1.8 服務概覽
平臺具備服務概覽功能，包含已釋出的API數量、未釋出API數量、呼叫API成功次數、呼叫API失敗次數、錯誤碼分佈等統計功能，以及檢視編輯且未釋出（草稿狀態）的API列表。
圖1-8-1
二、極光資料服務平臺架構設計
2.1 產品架構圖
圖2-1-1
資料服務平臺從產品層面，主要分為四層：
1、應用層：業務根據需求可以申請呼叫某些API獲取資料 。
2、功能層：平臺提供從API建立->API除錯->API釋出->API監控等功能。
3、支撐層：支撐平臺使用的一些基礎功能，包括：使用者管理、角色管理、日誌管理、工單審批等功能。
4、資料來源層：資料儲存元件，包括：pika、redis、hbase、mysql、es等。
2.2 技術架構圖
圖2-2-1
資料服務平臺主要分為兩部分：
【管理端】：
管理端主要提供給業務開發使用，通過管理端，業務開發能夠快速完成配置資料來源 ->開發API -> 釋出API等操作。
【服務端】：
服務端提供對內或對外API介面訪問，這裡又分為三層：
閘道器層：API呼叫入口，主要負責認證、許可權、API路由、限頻、限流等工作。
介面層：提供API介面查詢服務，根據API資訊組裝引數和返回查詢結果。
資料訪問層：該層提供訪問業務資料儲存元件。
2.3 整體互動圖
圖2-3-1
API釋出者通過管理端生成併發布API後，API介面後設資料資訊（資料來源、入參、出參、QPS、QPD等資訊）會被存放到redis，供認證中心、閘道器、可配置服務使用。
2.4 可配置化介面服務
在資料服務平臺一期建設中，提供基於pika和redis可配置化（NoSQL API）介面能力，其資料來源是通過jcache代理層連線pika和redis，業務資料 以KV方式儲存，可按照簡單的key-value對外提供服務，把key作為入參，value作為出參來抽象對外提供的API介面。
可配置化介面服務對外提供一個抽象介面，在本抽象介面中按照介面id獲取介面的後設資料資訊（資料來源、入參、出參等），再按照介面後設資料資訊建立資料來源連線，生成儲存key，獲取value值，最後封裝出參返回。
圖2-4-1
使用者身份認證、api呼叫許可權認證、限流等前置邏輯都通過後，進行api轉發。在資料服務平臺建立釋出的任意路徑api（Jcache可配置介面），經過閘道器都會轉發到可配置介面服務的抽象api中。
三、後續規劃
雖然一期功能已經上線，但只能滿足部分業務需求，還有很多功能需要完善和開發，以下是二期功能：
資料來源支援更多儲存元件，如：hbase、mysql、es、hive等
增加配置API的前置處理和後置處理能力
實現API服務編排功能，支援服務序列、並行、分支等能力
增加API介面的彈性伸縮和資源隔離功能
增加註冊API功能，業務可以將現有的API註冊到資料服務平臺
在一期產品功能基礎上，結合業務需求，完善平臺功能