背景
- 随着攜程酒店資料的膨脹以及個性化需求的增多，每個資料接口個性化的排期開發，因為沒有标準化，從需求讨論，資料準備、接口封裝、上線調試到接口api說明，期間需要花費大量的時間。一個接口的實作到生産上線至少需要2天甚至更多時間，這個時間成本不得不依賴排期開發；
- 随着曆史接口的疊代，已對外提供的700多資料接口中，其中500多個還在使用，并且每年的增量在100多，開發和維護成本高，特别是在追溯上遊離線資料邏輯的時候，過于依賴研發資源；
- 不同研發團隊技術棧不一樣，算法相關的研發更多偏向于python開發，對外輸出的接口也是由python實作，但公司架構對java接口有更友好的支援，不同技術棧對外輸出接口的穩定性存疑，特别是人員流動，團隊職責變化後，同時也影響維護成本；
- 随着業務的發展，各個業務系統的資料需求越來越多，需求響應要求也越來越高；
- 通過曆史接口的分析歸類，80%以上的資料接口其實是針對離線資料或者實時資料加上需求方的檢索條件傳回資料，沒有過多的加工邏輯或者過于複雜的業務邏輯在接口中實作；
為了能更快速支援業務個性化需求和降低研發成本，起到降本增效的效果，同時避免煙囪式資料接口開發，提高資料複用率，避免同樣資料出現同樣的多個接口，也避免不同的研發團隊拿到同一份資料都在做自己場景的資料接口，減少資料孤島情況。為此，我們設計了一套符合需求的資料服務平台。
一、平台介紹
統一資料服務平台依托于公司soa服務基礎之上建構，平台實作統一技術方案，降低營運成本，提升了接口穩定性，可維護性和持續性；
運維配置，降低資料接口實作成本，從個性化開發的2d+ 降低到4h甚至更快的上線，這個實作基本上可以不強依賴資源排期；
通過統一資料服務平台可視化界面配置，不依賴java開發人員介入，可由數倉團隊産出hive表根據需求配置接口輸出；
統一資料源，保證了資料使用的一緻性；
為需求方申請接口提供标準模闆，提升溝通效率以及需求方對大資料需求的滿意度。
系統層面架構圖：
接口的申請配置流程如下圖：
二、如何實作
2.1 平台收口
減少資料接口的輸出團隊和技術方案；另外随着業務量、資料量的增長，業務類型的累積，現在的接口不是完全靠mysql能支撐的，平台統一規劃技術方案，調用方不用關心底層服務是用clickhouse，es，starrocks，redis等任何資料庫以及相關資料庫的技術特性和文法特征。在實際配置中，我們需要結合調用方的場景以及不同的olap資料庫的特性和優缺點來選擇；比如：
ES：核心，高并發非KV結構的搜尋場景；
Redis：核心，高并發KV結構場景；
MySql：核心，千萬級以内小表簡單查詢并且是高并發場景；
starrocks：次核心，QPS不是非常高，單表資料量在千萬級，億級場景；
ClickHouse：非核心， QPS在100以内，資料量在千萬級，億級場景；
Trocks/ Hbase：非核心的KV結構場景；同時，對于不同的資料庫，更新機制上也是需要我們注意的哪些适合于全量更新，哪些适合于增量更新；
2.2 加強資料利用
有些資料隻要表同步過，下次在其他業務場景使用的時候隻要配置不同的查詢sql就可以對外提供使用，通過血緣關系的監控，減少離線資料的重複同步，提升一份資料的應用面，進而提升資料的可用性和一緻性，讓資料複用而不是複制。
2.3 接口安全驗證
每個調用方appid需要提前申請對某個接口的應用權限，統一服務平台通過授權token的方式，驗證appid+token的權限防止未申請接口權限的應用非法調用，其中appid是通過公司soa架構自動擷取避免appid被串改的情況，保證接口資料的安全性和穩定性。
2.4 限流保護
在一個高并發系統中對流量的把控是非常重要的，特别是在統一服務平台，當某個接口因為外部爬蟲原因導緻流量超過設定的閥值而沒有攔住，可能導緻整個平台對外輸出接口都不可用。
為此，我們引入Sentinel限流機制。Sentinel是面向分布式服務架構的輕量級流量控制元件，主要以流量為切入點，從限流、服務降級、系統負載保護等多個次元來幫助我們保障服務的穩定性。
實作原理是根據指定的時間内生成預先配置好的令牌數，每一個請求都會消耗一個令牌，令牌申領完後就會拒絕服務。目前每一個接口名都會有一個獨立的令牌，各接口間限流互相不幹擾實作對每個接口的流量控制，qps超過設定閥值接口自動熔斷。
2.5 資料緩存
接口的配置資訊，這些資訊持久化的存入硬碟中，在接口調用時會被頻繁使用，如何快速高效的擷取這些配置資訊，需要使用到緩存機制。通過建立主動和被動緩存，避免伺服器負載過高。資料源的配置資訊定時緩存，接口在使用時能快速取到基礎資料，不需要初始化。
2.6 服務契約統一
通過本平台調用的接口，現在所有的請求都是由一個入口中來完成。接口收到請求後根據接口的配置資訊自動的進行分流處理。請求契約中包含head和params兩部分，head負責接口的基本資訊，用于服務驗證和業務中轉。params參數為json字元串參數對象，服務會動态根據json的資訊與配置資訊比對進行解析參數。response契約中包含接口成功标志和result部分，其中result為json的字元串參數對象，需要調用方收到後進行解析。
Request如下圖所示：
Response 如下圖所示：
2.7 資料服務配置和映射
一個服務接口由資料源、sql語句、請求參數及響應參數組成。其中sql語句中的參數使用 ?、{序号} 占位符替代，與請求參數一起使用，sql有多少個參數占位符，請求參數就需要配置多少，接口運作時會根據請求的參數自動比對到sql參數中。響應參數為了在查詢結果中映射字段，sql查詢輸出的結果 ，可以通過映射轉換真正想要的輸出參數，配置的響應參數就是接口服務傳回的查詢結果。如下圖是配置sql的查詢方式：
2.8 契約文檔自動生成
個性化接口開發，需要對接口進行解釋，告知調用方如何調用。結合接口輸入和輸出參數都是自定義的特點，定義一套服務文檔展示模闆，文檔中包含所有的調用該接口的詳細資訊。隻要定義好接口後，會動态的生成契約文檔，申請使用該服務的團隊會通過郵件方式發送資訊，節省接口解釋成本。文檔線上效果如下圖，同時也會以郵件形式推送給申請人。
2.9 服務監控
服務接口正常運作後，借助于公司的clog和ck日志架構來監控接口調用情況。Clog監控主是要記錄請求接口從開始調用到傳回所有的過程記錄，包含每個過程節點的調用時長，請求參數及傳回參數。友善定位接口request的整條鍊路。ck監控主是要記錄接口層請求的參數，傳回的參數和響應時間。每次請求隻記錄一次，可以統計，監控每個時段調用的次數，接口響應的時長等資訊。
2.10 生産運作效果
2021年12月初上線至今，目前對接調用方appid 10個，提供100多個接口服務。請求量随着接口的增加趨勢增長，目前每天的請求量達390多萬次。每個接口上線周期為半天時間或更短。接口上線隻需要根據需求方配置後立刻就可以線上使用，大大的減少了上線的周期。生産接口響應時間91.49%在10ms内，99.99%是在100ms以内。
三、後期展望
現在所有的接口都部署在一個叢集，對于一些調用方，我們其實也可以區分高中低三個等級，将高優調用方部署在一個獨立叢集上，中等調用方部署在一個叢集上，低優調用方部署在獨立叢集上，互相之間資源隔離。
實作測試環境的打通。由于大資料環境大部分隻有生産環境，沒有測試環境和測試資料，是以統一服務平台現在隻能用于生産環境。開發環境或者測試環境無法調用聯調，對于調用方隻能通過mock的方式測試，這個也是後面我們需要考慮如何利用最低的成本實作測試環境的可用性，讓調用方使用起來更加便捷。
【作者簡介】
小豐，攜程研發總監，專注于分布式資料庫研究，大資料領域實時計算和大資料應用的系統架構設計。