亚洲精品啪啪啪,免费久久一级欧美特大黄,制服人妻中文自拍无码

阿里工程師教你 3 分鐘實現數據源編排和接入

作者| 阿里文娛高級開發工程師天甘慕理

責編 | 屠敏

頭圖 | CSDN 下載自東方 IC

背景

你一定也深有同感，在開發業務需求時，1/3是時間都花費在了前期準備工作上。比如，調研數據來自哪里，查看幾條真實數據及其結構，然后開始寫代碼過濾出所需要的數據，并將數據組裝成期望的結構……經過漫長的過程后，才能進入正題。今天我將介紹，如何通過元數據中心，幫你直接提升開發效率。

什么是元數據中心？它有兩個主要作用：沉淀數據源廣場、自定義接口。

1）數據源廣場：通過關鍵字搜索出基礎平臺服務相關接口，可手動快速調用查看接口；

2）自定義接口：根據業務自定義所需字段(字段名、類型)，元數據中心SDK還將接口調用這一系列邏輯抽象出來，沉淀了“接口調用引擎”，業務開發只需要將平臺下發的接口標示傳入引擎中，即可完成接口接入，由hardcode轉為配置化。

除以上兩點，元數據中心還建立了統一監控、熔斷能力，采用多線程池，保證接口調用的效率及穩定性。

架構

元數據中心有兩個核心模塊：1）數據源，對基礎平臺服務(像需求中的ABCD系統)接口做標準化調用；2）自定義接口，為業務開發做接口編排，包括入參和出參的定義。

1、數據源

數據源模塊是將基礎平臺服務接口做了標準化調用，與其他平臺標準化不同的是，基礎平臺服務不需要實現JAVA接口，這樣降低了基礎服務接入。目前元數據中心暫時支持HTTP及RPC接口，后面我們會逐步支持分布式數據庫數據源，分布式緩存數據源及mock數據源。數據源模塊采用以下技術來保證調用的穩定：

數據源模塊采用多線程池技術，不但可以并發調用，保證接口調用的穩定，還可以根據接口調用情況動態調整所使用的線程池，保證在某個接口性能較差情況下不影響其他接口的調用；
使用了泛化調用技術，泛化調用技術避免了引入二方包導致包沖突的問題；
數據源模塊還支持分批調用，很多諸如queryByIdList這種查詢，肯定需要對查詢ID做count限制，但是有時候業務所需要的單次查詢數多于限制數，那么就需要分批并發調用多次，然后再merge結果；
利用ThreadLocal技術元數據中心還支持對接口調用的超時時間做動態的調整，有些業務為了獲取到數據可以容忍較長的RT，有些業務對RT比較敏感，所以可以根據業務不同對超時時間做個性化設置。

2、業務自定義接口

1）Schema的定義

通常在業務開發時，接口主要解決兩件事：1）對接底層的數據源，2）用幾個數據源的結果組合成一個業務接口暴露給上層的業務。因此，在設計Schema時考慮了以上兩點，將Schema分為調用和返回，根據不同的需求配置調用哪些數據源，并配置這些數據源的依賴關系，并且配置接口需要以什么樣的方式返回，可直接透出數據源的返回結果，對結果進行簡單維護，也可以自己定義結果，并指定取值的來源，對結果的類型和結構進行控制和干預。

2）Schema執行引擎

第一：簡述執行過程

首先解決依賴關系，然后進行數據源調用，調用后再根據返回配置來處理。這里如果返回值配置的是一個表達式，那么引擎直接執行這個表達式來作為中間結果，并根據特殊配置對中間就結果進行處理。如果沒有指定配置表達式，而是指定了自己需要的哪些字段，引擎會根據這些字段值的表達式分別進行設置，如果這個字段是一個嵌套，引擎對嵌套的Schema進行遞歸處理。

第二：如何解決數據源依賴

有很多使用場景是一個業務接口需要兩個數據源的支持。對于依賴，抽象出一個依賴解決器，它會遍歷所有的數據源調用，分析調用關系并生成一顆依賴樹。在調用時，對樹進行層次遍歷和先序遍歷，保證先執行到無依賴的調用，再處理有依賴的調用。舉例，總共需要調用8個數據源分別為A、B、C、D、E、F、G、H，其中C依賴A，D依賴A和B，E依賴B，G依賴C，F依賴C和D，H依賴E。下圖表示生成的依賴樹：

如圖所示，其中先按層次遍歷ROOT，但這是一個虛擬的節點不處理，之后調處理A和B，這里可以并發調用，也可以順序調用，交給數據源調用層來處理。A和B處理完成后，處理A的子節點和B的子節點C、D、F。直到所有節點都處理完畢。

第三：如何映射結果

引擎調用數據源后，需要根據表達式來進行結果映射。如果是需要自定義返回的每一個key，比如調用視頻查詢，默認返回的key為id，而需要向業務方返回的是vid，可配置key的值表達式。設計時希望表達式盡量簡單，于是設計出了這樣一種表達式，比如vid，可配置為datasource.video.response.id。

3）動態腳本的執行與優化

第一：為什么選擇Groovy

因為整體技術棧是Java，因此首選的腳本語言就是基于JVM，而選擇Groovy一是因為成熟，同時語法比Java簡潔，二是因為接入簡單（只需一個jar包），三是因為本身兼容Java的大部分語法，學習成本較低。

第二：Groovy遇到的問題和解決辦法

主要是安全問題和性能問題。安全的問題非常嚴重，因為腳本是交給用戶輸入的，所以很容易出現風險代碼。系統對Groovy的編譯器進行了一系列自定義，同時使用沙箱，將代碼進行攔截，過濾掉敏感操作，最大化避免風險代碼的執行。

性能上，Groovy的性能遠比Java慢，于是進行了一番優化，比如將Groovy的代碼進行預編譯和緩存，保證執行時不會發生編譯動作，保證執行一個Groovy單條腳本不會有太大的性能問題。

第三：最終解決方案

經過測試，發現Groovy本身的執行效率還是要低，因為一次請求可能需要執行成百上千次的腳本，一次執行的性能問題不明顯，但是多次執行問題很容易就暴露出來，比原生的Java執行仍然有百倍的差距。

這個既然是Groovy的問題，并且無解，就想到了是否可以用其它的方式替換Groovy，于是研究了各種表達式引擎包括Aviator、FEL、MVEL、JSONPath、Java動態編譯。并且對這些代碼進行測試，使用兩條語義相同的代碼，分別編寫了不同腳本的版本，與Java原生的代碼進行比對。長時間運行后結果如下：

上圖為兩個腳本執行1000次的耗時，發現使用Java動態編譯和JSON-Path，性能比Groovy提升了約150倍。但是缺點也非常明顯：JSON-Path是能寫單行的取值語句，而Java語法復雜、不方便寫內部類和方法等。考慮到使用場景，Java和JSON-Path滿足95%以上的場景，可再用Groovy寫更復雜的腳本。

穩定性

穩定大于一切，接口調用穩定性是重要一環，如何保證穩定性呢？1）有問題時要能及時的報警，2）為了整個應用的穩定性，需要自動熔斷。

1、監控報警

因為元數據中心SDK是去中心化的，接口的調用邏輯發生在業務應用本地，SDK利用logback的Appender擴展將日志異步發送到日志服務中，再用監控平臺采集日志服務的日志，在監控平臺中完成監控報警的搭建。元數據中心SDK還集成了調用鏈監控平臺，不但可以在業務應用對應的調用鏈監控平臺上看到接口調用情況，還利用了logback的ClassicConverter擴展，在日志中統一加入調用鏈唯一ID,方便通過該ID查看全鏈路日志，以達到快速定位問題的目的。

2、熔斷降級

如果你的應用有外部依賴，那么保證系統穩定性，熔斷是必不可缺的手段。想象一下，某個依賴的RT突然變高，如果沒有及時熔斷，那么你應用的線程池資源很快會被該依賴消耗完，且整個應用將無法響應，造成雪崩，所以熔斷的重要性是不言而喻的。元數據中心目前支持三種熔斷策略：RT、秒級異常比例、分鐘異常數。

實踐提效

說了這么多，究竟能否為業務開發提效呢。實踐是檢驗真理的唯一標準，接下來讓我們一起來看下元數據中心如何與業務結合，為業務開發提效。

1、與內容分發開發框架集成

目前優酷主APP業務基本上是統一的內容分發開發框架開發的，那么與內容分發開發框架集成，是為業務開發提效最好的切入點。內容分發開發框架雖然具有強大的配置能力，但是它的數據源開發還是面臨到處找接口，學習怎么調用，然后引入二方包，hard code，提測，aone發布一系列漫長而重復的操作。另外一旦有接口需要切換或者業務需要增加字段等變更操作，還需要通過hard code方式改動，這樣不但開發效率比較低，頻繁的發布還增加了系統不穩定性。結合元數據中心的目標，內容分發開發框架集成元數據中心就可以完美解決它的痛點：

接口接入不再需要hardcode，通過配置即可完成；
接口需要切換或者業務需要增加字段時，不需要hard code，在元數據中心做切換，做字段的增加，然后通過腳本語言動態的將字段讀取出來；
無需重復的打印監控日志，也不需要單獨做熔斷，由元數據中心統一處理。

再來看看開發者的反饋情況，最近與業務開發同學了解到，目前開發新組件的需求中有涉及需要讀取某些數據，通過元數據中心配置了相關接口和所需字段，且結合開發框架的配置能力，從開發到上線基本沒有hard code,通過配置快速的上線驗證。

2.與Faas集成

眾所周知，互聯網產品講究的是快速迭代和試錯，業務需要具備快速上線能力，與競爭對手PK。這就意味著背后的技術研發流程需要更加高效，元數據中心與Faas結合就可以實現快速上線的效果。因為業務開發通過元數據中心可以快速接入接口，再結合Faas的開箱即用特點，直接編寫業務邏輯，保存之后自動完成構建、部署，整個流程簡單、高效。足以達到快速上線驗證的目的。前優酷小程序業務已經在元數據中心+Faas下上線了很多業務。