基于PB級海量數(shù)據(jù)實現(xiàn)數(shù)據(jù)服務(wù)平臺，需要從各個不同的角度去權(quán)衡，主要包括實踐背景、技術(shù)選型、架構(gòu)設(shè)計，我們基于這三個方面進行了架構(gòu)實踐，下面分別從這三個方面進行詳細分析討論：

一、實踐背景

該數(shù)據(jù)服務(wù)平臺架構(gòu)設(shè)計之初，實踐的背景可以從三個維度來進行說明：當(dāng)前現(xiàn)狀、業(yè)務(wù)需求、架構(gòu)需求，分別如下所示：

[[205831]]

二、當(dāng)前現(xiàn)狀

收集了當(dāng)前已有數(shù)據(jù)、分工、團隊的一些基本情況，如下所示：

• 數(shù)據(jù)收集和基礎(chǔ)數(shù)據(jù)加工有專門的Team在做，我們是基于收集后并進行過初步加工的基礎(chǔ)數(shù)據(jù)，結(jié)合不同行業(yè)針對特定數(shù)據(jù)的需求進行二次加工的。
• 數(shù)據(jù)二次加工，會集成基礎(chǔ)數(shù)據(jù)之外的其它有業(yè)務(wù)屬性的數(shù)據(jù)，比如引入第三方POI數(shù)據(jù)等。
• 原始數(shù)據(jù)每天增量大約30~40TB左右。
• 計算集群采用Spark on YARN部署模式，大約400個節(jié)點。
• 所有數(shù)據(jù)各種屬性、行為信息，都是圍繞大約40億的移動設(shè)備ID進行很多倍膨脹，比如每天使用微信App的設(shè)備的行為信息。
• 參與該平臺的研發(fā)人員，對實際數(shù)據(jù)業(yè)務(wù)需求了解不會非常深入，因為跨多個行業(yè)及其不同數(shù)據(jù)需求的變化較快。

三、業(yè)務(wù)需求

另外，實現(xiàn)的該數(shù)據(jù)服務(wù)平臺，需要滿足當(dāng)前的基本數(shù)據(jù)業(yè)務(wù)需求，主要包括使用平臺的人員特點，需要支撐的各種基本數(shù)據(jù)需求，經(jīng)過梳理，如下所示：

平臺初期面向內(nèi)部業(yè)務(wù)人員使用，幾乎沒有技術(shù)背景。

40億+的移動設(shè)備大表，包含各類設(shè)備ID及其設(shè)備屬性，需要提供批量匹配功能：給定一類或多類設(shè)備ID的批量文件，從大表中獲取到匹配上的設(shè)備信息(ID及多個屬性信息)。

對PB級數(shù)據(jù)進行各種快速探索，輸入各種過濾條件，如地域(國家/省/市/區(qū))、地理圍欄(地圖圈選/上傳文件/直接輸入)、使用的App及分類(安裝/活躍)、時間范圍(日/周/月)、POI及分類等等，理論上不限制條件個數(shù)，經(jīng)驗值最多在5~6個左右。

輸出主要包括明細信息、多維度統(tǒng)計(畫像)、圖表(熱力圖)等。

平臺提供的數(shù)據(jù)服務(wù)，都是批量模式的計算，所以需要為用戶提交的數(shù)據(jù)作業(yè)，給予準(zhǔn)確的狀態(tài)變化反饋。

有小部分面向開發(fā)人員的需求：將在數(shù)據(jù)平臺Web系統(tǒng)操作進行的數(shù)據(jù)匹配、提取、探索等操作，進行服務(wù)化以供其他系統(tǒng)中的服務(wù)調(diào)用。

四、架構(gòu)需求

在未來業(yè)務(wù)模式變化的情況下，能夠非常容易地擴展，并盡量復(fù)用大部分核心組件。同時，還要面向開發(fā)人員復(fù)用數(shù)據(jù)平臺的數(shù)據(jù)業(yè)務(wù)服務(wù)，以增加平臺利用率，間接產(chǎn)出數(shù)據(jù)價值。考慮如下一些當(dāng)前需要以及未來可能演變的架構(gòu)需求：

• 定義作業(yè)和任務(wù)的概念：作業(yè)是用戶為滿足一次業(yè)務(wù)需要而提交的數(shù)據(jù)獲取請求，最終輸出想要的數(shù)據(jù)結(jié)果;任務(wù)是為滿足輸出一個作業(yè)結(jié)果，從邏輯上拆分成的基本計算單元。一個作業(yè)由多個任務(wù)的計算組合而完成。
• 對于一個作業(yè)輸入的多個過濾條件，如果作為一個單獨的計算任務(wù)，根本無法在PB量級的數(shù)據(jù)上輸出結(jié)果，所以需要將作業(yè)拆分成多個任務(wù)進行分別計算，最后輸出結(jié)果。
• 對用戶作業(yè)狀態(tài)的管理，具有一定的業(yè)務(wù)含義，基本不能在公司級別進行復(fù)用，具體涉及內(nèi)容包括：排隊、組成作業(yè)的任務(wù)列表管理、作業(yè)優(yōu)先級管理。
• 任務(wù)是最基本的計算單位，設(shè)計能夠協(xié)調(diào)整個任務(wù)計算的架構(gòu)，可以分離出任何業(yè)務(wù)狀態(tài)，實現(xiàn)為無狀態(tài)的任務(wù)計算架構(gòu)，在公司級別可以復(fù)用，比如大量基于Spark的計算可以抽象為任務(wù)計算。
• 由于時間范圍條件跨度需要支持幾年(如1~3年)，計算依賴的數(shù)據(jù)量級在TB甚至PB級別，所以一定要通過預(yù)計算的方式壓縮數(shù)據(jù)，并能提供支持快速計算的方式。
• 預(yù)計算可以使用Spark計算集群，每天通過控制計算所需資源進行大規(guī)模ETL處理。
• ETL處理，迫切需要一個簡單、輕量的ETL作業(yè)調(diào)度系統(tǒng)，可以從開源產(chǎn)品中甄選。
• 采用原生Spark計算基本無法為平臺上用戶提供快速計算的體驗，可能會考慮列式分布式數(shù)據(jù)庫，或基于Bitmap結(jié)構(gòu)的分布式計算系統(tǒng)。
• 面向開發(fā)人員，部分涉及業(yè)務(wù)相關(guān)內(nèi)容的模塊，第一階段可以通過硬編碼方式處理業(yè)務(wù)邏輯，后續(xù)第二階段可以基于對業(yè)務(wù)流程的熟悉來進行改造，抽取通用業(yè)務(wù)邏輯規(guī)則，構(gòu)建能夠快速交付業(yè)務(wù)功能的模塊。
• 對平臺架構(gòu)進行分解，分離有狀態(tài)和無狀態(tài)模塊，分離帶業(yè)務(wù)屬性和不帶業(yè)務(wù)屬性的模塊，保持模塊輕量易于隨架構(gòu)演進進行改造、升級、維護。

五、技術(shù)選型

技術(shù)選型，主要從如下幾個方面進行考慮：

六、數(shù)據(jù)存儲

1、原始數(shù)據(jù)存儲

數(shù)據(jù)量級達到PB級，所以，作為整個數(shù)據(jù)服務(wù)平臺的最初輸入數(shù)據(jù)，我們稱為數(shù)據(jù)服務(wù)平臺的原始數(shù)據(jù)，后續(xù)簡稱原始數(shù)據(jù)，這些原始數(shù)據(jù)是直接存儲在HDFS文件系統(tǒng)中，根據(jù)時間的維度，分為小時數(shù)據(jù)、日數(shù)據(jù)、月數(shù)據(jù)。這樣，可以根據(jù)數(shù)據(jù)計算需要，按照小時、日、月進行加工處理，能夠在可允許的計算資源配額和計算時間范圍內(nèi)完成處理。

另外，根據(jù)每天大約30~40TB的增量數(shù)據(jù)，原始數(shù)據(jù)采用parquet格式壓縮存儲，我們進行二次加工的輸出仍然是以parquet格式存儲。

2、分布式關(guān)系數(shù)據(jù)存儲

對于PB級的數(shù)據(jù)，想要在數(shù)據(jù)服務(wù)平臺中快速為用戶提供數(shù)據(jù)服務(wù)，根據(jù)業(yè)務(wù)特點，存儲在適合快速加載、快速計算的分布式數(shù)據(jù)存儲系統(tǒng)中。

快速加載，必然要對數(shù)據(jù)進行特殊格式處理，并在一定程度上壓縮數(shù)據(jù)，這樣才能減少數(shù)據(jù)加載時間。可以很容易想到，使用支持列式存儲的分布式數(shù)據(jù)庫。比如Vertica分布式數(shù)據(jù)庫就是一款支持列式存儲的MPP數(shù)據(jù)庫。Vertica是HP開發(fā)的商用分布式數(shù)據(jù)庫，同時也發(fā)布了開源的免費社區(qū)版本，不過社版本有一定限制：只支持1TB原始數(shù)據(jù)、3節(jié)點集群規(guī)模。如果變通一些，可以通過Vertica社區(qū)版本進行改造以支持解除3個節(jié)點集群規(guī)模和1TB存儲的限制，不過要在分片邏輯控制、分片數(shù)據(jù)一致性方面做更多工作，尤其是面向上層應(yīng)用提供單一的統(tǒng)一存取視圖是非常必要的。因為列式存儲支持計算時只加載用于計算的列，故而能夠達到快速加載的目的。

快速計算，首先要求計算能夠并行化，那么數(shù)據(jù)就應(yīng)該分片存儲，使數(shù)據(jù)計算本地化。Vertica自然能夠?qū)崿F(xiàn)數(shù)據(jù)的并行計算，我們在前期使用過程中驗證了，對于從40億+的大表中批量匹配出任意信息(匹配ID，以及ID對應(yīng)的關(guān)聯(lián)表中的其它明細信息)，效率非常好，基本分鐘級便可以輸出匹配結(jié)果。

我們也對開源不久的MPP數(shù)據(jù)庫Greenplum進行了調(diào)研，它原生支持分布式架構(gòu)，支持列式和行式兩種存儲，自然具有Vertica對應(yīng)的列式存儲的優(yōu)勢，又不需要手動對分片進行管理控制，但性能要比Vertica差一些。然而，Greenplum數(shù)據(jù)庫能夠支持數(shù)組類型，支持多種編程語言的UDF，結(jié)合我們之前做過很多有關(guān)Bitmap的實踐，采用開源的RoaringBitmap，能夠很好的基于Greenplum實現(xiàn)快速的Bitmap計算。

3、消息存儲

消息存儲，主要是用來解耦后臺多個較重的系統(tǒng)之間的通信。因為本身這類系統(tǒng)比較重，如果采用RPC調(diào)用的方式進行通信，某個系統(tǒng)進行升級，會導(dǎo)致依賴于該系統(tǒng)提供服務(wù)的其它系統(tǒng)管理更多的特殊情況處理。而采用消息機制，使得各個系統(tǒng)之間不需要關(guān)注交互系統(tǒng)處理狀態(tài)，而對消息交換只需要關(guān)注消息的生成和消費。

這樣，我們可以隨時對系統(tǒng)進行改造、升級、Bug修復(fù)重啟等操作，而不會使整個平臺陷入不可控的狀態(tài)。消息中間件，我們選擇使用RabbitMQ。

六、數(shù)據(jù)處理

數(shù)據(jù)處理，主要包括原始數(shù)據(jù)ETL處理、應(yīng)用數(shù)據(jù)計算兩大類：

1、原始數(shù)據(jù)ETL處理

基于HDFS存儲的數(shù)據(jù)，最方便最高效的技術(shù)方案，自然是使用Spark計算集群來對數(shù)據(jù)進行ETL處理。我們基于原生的Scala編程語言來開發(fā)各種ETL程序，實現(xiàn)數(shù)據(jù)清洗、抽取、轉(zhuǎn)換操作。

2、應(yīng)用數(shù)據(jù)計算

數(shù)據(jù)服務(wù)平臺中，面向用戶的應(yīng)用數(shù)據(jù)計算，基于Greenplum數(shù)據(jù)庫支持的SQL語言來實現(xiàn)數(shù)據(jù)處理，并基于Java編程語言來實現(xiàn)整個應(yīng)用服務(wù)的開發(fā)。

七、ETL作業(yè)調(diào)度

數(shù)據(jù)處理需要進行大量的ETL計算，管理各種計算任務(wù)之間的依賴關(guān)系及其調(diào)度，我們采用了非常輕量的Azkaban調(diào)度系統(tǒng)。

八、業(yè)務(wù)元數(shù)據(jù)管理

業(yè)務(wù)元數(shù)據(jù)，主要用于支撐數(shù)據(jù)服務(wù)平臺Web UI上面的各種業(yè)務(wù)條件選項，比如，常用的有如下一些：

• 移動設(shè)備機型、品牌、運營商、網(wǎng)絡(luò)、價格范圍、設(shè)備物理特性
• 應(yīng)用名稱、包名、哈希值
• 應(yīng)用分類
• 地域信息，如國家、省份、城市、區(qū)縣
• POI名稱、地址
• POI分類，包括一級分類、二級分類

這些元數(shù)據(jù)，有些來自于基礎(chǔ)數(shù)據(jù)部門提供的標(biāo)準(zhǔn)庫，比如品牌、價格范圍等，可以從對應(yīng)的數(shù)據(jù)表中同步或直接讀取;而有些具有時間含義的元數(shù)據(jù)，需要每天通過ETL處理生成，比如應(yīng)用信息;POI數(shù)據(jù)需要從外部抓取，并進行處理，一般每個月更新一次。

這些元數(shù)據(jù)，為支撐應(yīng)用計算使用，被存儲在MySQL數(shù)據(jù)庫中;而對于填充頁面上對應(yīng)的條件選擇的數(shù)據(jù)，則使用Redis存儲，每天/月會根據(jù)MySQL中的數(shù)據(jù)進行加工處理，生成易于快速查詢的鍵值對類數(shù)據(jù)，存儲到Redis中。

九、數(shù)據(jù)服務(wù)

數(shù)據(jù)服務(wù)，主要支撐后臺的數(shù)據(jù)應(yīng)用，全平臺采用標(biāo)準(zhǔn)的REST接口風(fēng)格來定義，主要使用Spring Boot來快速開發(fā)對應(yīng)的接口。

1、離線批量服務(wù)進行REST接口封裝

還有一點我們需要遵循的是，任何具有復(fù)雜的數(shù)據(jù)處理邏輯的服務(wù)，都通過一層REST接口進行封裝，將全部的離線批量服務(wù)后置。這樣得到一個聚合服務(wù)的REST接口層，該層主要負責(zé)定義和管理接口的各個請求、響應(yīng)參數(shù)，REST接口不變，而對應(yīng)的數(shù)據(jù)處理邏輯可以根據(jù)實際情況進行調(diào)整，以后對存儲或計算方案進行升級改動，都不影響使用上層REST接口調(diào)用方。

2、Greenplum服務(wù)網(wǎng)關(guān)

比如，我們采用Greenplum數(shù)據(jù)庫，在Greenplum前面增加了一層Greenplum服務(wù)網(wǎng)關(guān)，對于任何需要訪問Greenplum數(shù)據(jù)庫的應(yīng)用，必須通過與Greenplum服務(wù)網(wǎng)關(guān)進行交互，而不是直接去訪問Greenplum數(shù)據(jù)庫。理想狀態(tài)下，Greenplum服務(wù)網(wǎng)關(guān)可以實現(xiàn)為無狀態(tài)的服務(wù)網(wǎng)關(guān)，通過Nginx做反向代理實現(xiàn)HA，這樣后續(xù)因為業(yè)務(wù)變更，可以非常平滑地進行變更和升級，而不影響依賴于Greenplum服務(wù)網(wǎng)關(guān)的業(yè)務(wù)接口調(diào)用。

3、微服務(wù)

除了數(shù)據(jù)服務(wù)平臺內(nèi)部進行服務(wù)調(diào)用，最外層通過Web界面的風(fēng)格，只需要拖動或選擇可視化組件，實現(xiàn)對非技術(shù)背景的業(yè)務(wù)用戶進行數(shù)據(jù)提取和分析，未來我們還要將全部的服務(wù)暴露到外部(數(shù)據(jù)服務(wù)平臺所屬部門之外的其它部門，以及公司外部)，最大化數(shù)據(jù)服務(wù)的價值。

微服務(wù)部分，我們選擇了Spring Cloud來快速構(gòu)建微服務(wù)。

十、UI展示

UI層主要根據(jù)我們開發(fā)人員的技術(shù)背景，使用Vue來構(gòu)建面向業(yè)務(wù)用戶的數(shù)據(jù)服務(wù)Web系統(tǒng)。

十一、架構(gòu)設(shè)計

整個數(shù)據(jù)服務(wù)平臺的架構(gòu)設(shè)計，如下圖所示：

如上圖所示，對應(yīng)的各個核心子平臺及其服務(wù)，下面將分別詳細說明：

1、數(shù)據(jù)服務(wù)Web系統(tǒng)

數(shù)據(jù)服務(wù)Web系統(tǒng)是面向用戶使用的，主要通過可視化業(yè)務(wù)組件的方式，將數(shù)據(jù)服務(wù)暴露出來，方便業(yè)務(wù)用戶使用。同時，該系統(tǒng)提供用戶權(quán)限管理的功能，可以設(shè)置用戶權(quán)限，主要包括業(yè)務(wù)用戶和管理用戶。

數(shù)據(jù)服務(wù)Web系統(tǒng)的設(shè)計，如下圖所示：

該系統(tǒng)的設(shè)計比較容易，核心的思想就是前端和后端分離。前端定義的各種可視化組件，都是根據(jù)不同業(yè)務(wù)線的需求，經(jīng)過梳理分類，將需求頻度較高的抽象出來，做成業(yè)務(wù)功能組件。后端服務(wù)包括兩類：一類是業(yè)務(wù)元數(shù)據(jù)服務(wù)接口，包括各種需要在頁面展示的數(shù)據(jù)項，如設(shè)備機型、地域、應(yīng)用、POI等;另一類是作業(yè)管理服務(wù)接口，主要負責(zé)管理作業(yè)相關(guān)內(nèi)容，如作業(yè)查詢、保存等。

2、業(yè)務(wù)作業(yè)調(diào)度平臺

業(yè)務(wù)作業(yè)調(diào)度平臺是整個數(shù)據(jù)服務(wù)平臺最核心的子平臺之一，設(shè)計該平臺主要考慮除了當(dāng)前支撐面向業(yè)務(wù)用戶需求之外，還要能夠很好的擴展以支持其他業(yè)務(wù)部門開發(fā)人員對服務(wù)的使用。該平臺的架構(gòu)，如下圖所示：

該平臺主要負責(zé)作業(yè)的解析編排、排隊、調(diào)度。

作業(yè)編排采用調(diào)用外部編排服務(wù)的方式，主要考慮的是編排需要根據(jù)業(yè)務(wù)的一些屬性進行實現(xiàn)，所以將易變的業(yè)務(wù)部分從作業(yè)調(diào)度平臺分離出去。如果后續(xù)有對編排邏輯進行調(diào)整和修改，都無需操作業(yè)務(wù)作業(yè)度調(diào)度平臺。

排隊，支持多隊列排隊配置，比如根據(jù)當(dāng)前及其未來的發(fā)展趨勢，需要具有面向業(yè)務(wù)用戶的業(yè)務(wù)隊列、面向開發(fā)人員的服務(wù)隊列，而這兩種隊列所負責(zé)的作業(yè)調(diào)度的SLA是完全不同的，業(yè)務(wù)隊列中的作業(yè)每天可能成百上千個，而服務(wù)隊列在初期對于每個業(yè)務(wù)線只需要每天調(diào)用一次或多次(正常會嚴格限制服務(wù)調(diào)用數(shù)量)，初期從作業(yè)量上來看這兩個作業(yè)容量的比例大概是8:2，通過隊列來隔離調(diào)度，能夠更好地滿足具有不同需求的用戶。

調(diào)度，是對作業(yè)、以及屬于該作業(yè)的一組任務(wù)進行調(diào)度，為了簡單可控起見，每個作業(yè)經(jīng)過編排后會得到一組有序的任務(wù)列表，然后對每個任務(wù)進行調(diào)度。這里面，稍有點復(fù)雜的是，作業(yè)是一級調(diào)度，任務(wù)是二級調(diào)度，但是要保證屬于同一個作業(yè)的任務(wù)能夠按照先后順序被調(diào)度運行。所以，作業(yè)是排隊的基本單位，在每一個排隊單元中，要包含作業(yè)ID、任務(wù)個數(shù)、作業(yè)狀態(tài)，同時為能夠控制任務(wù)正確調(diào)度，也需要包含當(dāng)前調(diào)度運行中任務(wù)ID、運行中任務(wù)狀態(tài)，可見任務(wù)是調(diào)度運行的基本單位。被調(diào)度運行的任務(wù)會發(fā)送到RabbitMQ中，然后等待任務(wù)協(xié)調(diào)計算平臺消費并運行任務(wù)，這時作業(yè)調(diào)度平臺只需要等待任務(wù)運行完成的結(jié)果消息到達，然后對作業(yè)和任務(wù)的狀態(tài)進行更新，根據(jù)實際狀態(tài)確定下一次調(diào)度的任務(wù)。

另外，還有幾個點需要注意：第一，被調(diào)度運行的任務(wù)需要進行超時處理;第二，控制同時能夠被調(diào)度的作業(yè)(實際上運行的是作業(yè)對應(yīng)的某個任務(wù))的數(shù)量;第三，作業(yè)優(yōu)先級控制。

3、任務(wù)協(xié)調(diào)計算平臺

任務(wù)協(xié)調(diào)計算平臺也整個數(shù)據(jù)服務(wù)平臺最核心的子平臺之一，它是無狀態(tài)的，除了能夠支撐我們的數(shù)據(jù)服務(wù)平臺，如果有其它想要接入的任務(wù)，都可以通過該平臺協(xié)調(diào)來運行。該平臺的架構(gòu)，如下圖所示：

該平臺的設(shè)計是主從架構(gòu)，Master和Slave之間通過RPC調(diào)用進行通信，通信層使用了Netty網(wǎng)絡(luò)通信框架。Worker可以根據(jù)實際計算任務(wù)的壓力，進行水平擴展。

Master負責(zé)控制從RabbitMQ中拉取任務(wù)消息，然后根據(jù)Worker節(jié)點的資源狀況進行任務(wù)的協(xié)調(diào)和調(diào)度，并將Worker上作業(yè)完成的信息發(fā)送到RabbitMQ，供上游業(yè)務(wù)作業(yè)調(diào)度平臺消費從而控制更新作業(yè)的運行狀態(tài)。同時，Master管理注冊的Worker狀態(tài)、Worker資源狀態(tài)、Worker上運行的任務(wù)的狀態(tài)。

Worker是實際運行任務(wù)的工作節(jié)點，它負責(zé)將任務(wù)調(diào)度到后端的計算集群，或者調(diào)用數(shù)據(jù)處理服務(wù)來實現(xiàn)任務(wù)的運行。由于任務(wù)都是批量處理型計算任務(wù)，所以Worker要管理任務(wù)的提交，以及對已提交任務(wù)運行狀態(tài)的異步查詢(輪詢)。

4、Greenplum REST服務(wù)網(wǎng)關(guān)

Greenplum REST服務(wù)網(wǎng)關(guān)，直接與Greenplum數(shù)據(jù)庫進行交互，這樣起到保護Greenplum數(shù)據(jù)庫的作用。因為實際Greenplum數(shù)據(jù)庫集群的計算容量有限，不能無限支持很高并發(fā)，所以通過控制并發(fā)來加快每個計算任務(wù)。該REST服務(wù)網(wǎng)關(guān)的設(shè)計，如下圖所示：

上圖中，通過排隊機制來保護Greenplum，并進行任務(wù)的調(diào)度運行，所以該服務(wù)是有狀態(tài)的。而且，該服務(wù)具有一定的業(yè)務(wù)特征，根據(jù)不同的數(shù)據(jù)需求，需要對接口以及SQL進行調(diào)整，最好的方式是將業(yè)務(wù)接口與任務(wù)計算分離：業(yè)務(wù)接口層可以將調(diào)用任務(wù)保存到Redis隊列中，實現(xiàn)接口層的冗余部署和平滑升級，然后作為消費的任務(wù)處理服務(wù)直接消費Redis隊列中的任務(wù)，提交到Greenplum數(shù)據(jù)庫計算。

5、數(shù)據(jù)微服務(wù)平臺

數(shù)據(jù)微服務(wù)平臺，主要考慮復(fù)用已存在的數(shù)據(jù)服務(wù)，以及支撐數(shù)據(jù)服務(wù)的核心組件，如業(yè)務(wù)作業(yè)調(diào)度平臺、任務(wù)協(xié)調(diào)計算平臺等，為面向開發(fā)人員使用的服務(wù)調(diào)用，通過服務(wù)接口的方式暴露出來。數(shù)據(jù)微服務(wù)平臺的架構(gòu)，如下圖所示：

該平臺主要基于Spring Cloud構(gòu)建，使用Eureka作為服務(wù)注冊中心。由于整個數(shù)據(jù)服務(wù)平臺是以離線計算為主，沒有高并發(fā)、服務(wù)降級的、調(diào)用鏈跟蹤等需求，所以并沒有完全使用Netflix OSS中大部分組件，如Zuul、Hystrix等。如果后續(xù)需要，可以非常容地集成進來。

鑒權(quán)網(wǎng)關(guān)，是所有調(diào)用微服務(wù)平臺的外部調(diào)用方的入口。為了保證整個微服務(wù)平臺的正常運行，通過用戶、時間(調(diào)用期限)、調(diào)用頻率等限制調(diào)用方。比如某些業(yè)務(wù)線的應(yīng)用需要使用微服務(wù)平臺的服務(wù)，由于對方業(yè)務(wù)可能下線，而服務(wù)程序沒有下線，仍然持續(xù)調(diào)用我們平臺服務(wù)，這會對微服務(wù)平臺資源造成浪費。另外，也避免了服務(wù)調(diào)用方測試、調(diào)試，對整個微服務(wù)平臺造成不可控的狀況。

上圖左面，服務(wù)注冊中心及其以上部分，是整個微服務(wù)平臺的核心部分，我們在構(gòu)建該平臺時，也考慮了接入非微服務(wù)的組件。比如熱力圖服務(wù)，數(shù)據(jù)是需要批量處理生成，而訪問時是同步調(diào)用的，所以在數(shù)據(jù)服務(wù)平臺的Web部分提交的作業(yè)，如果是熱力圖類型，會調(diào)用微服務(wù)平臺的熱力圖服務(wù)異步生成數(shù)據(jù)，而用戶可以在Web系統(tǒng)中查看熱力圖(如果未生成則提示正在生成中);對其它上層數(shù)據(jù)應(yīng)用也可以直接調(diào)用微服務(wù)平臺的熱力圖服務(wù)生成數(shù)據(jù)，并下載對應(yīng)數(shù)熱力圖據(jù)。

6、其它服務(wù)/系統(tǒng)

其它服務(wù)/系統(tǒng)比較簡單，所以這里只是簡單說明一下：

• Java REST服務(wù)網(wǎng)關(guān)：要對某些從Greenplum數(shù)據(jù)庫中計算得到的數(shù)據(jù)，需要進行再加工處理以滿足實際業(yè)務(wù)，如熱力圖數(shù)據(jù)生成和壓縮等，將這些服務(wù)封裝成REST風(fēng)格接口調(diào)用。
• Spark REST服務(wù)網(wǎng)關(guān)：對于需要對HDFS上指定數(shù)據(jù)集處理，生成需要的結(jié)果數(shù)據(jù)，使用Spark開發(fā)程序，同時將Spark計算作業(yè)封裝成REST風(fēng)格接口調(diào)用。
• 數(shù)據(jù)ETL調(diào)度系統(tǒng)：使用開源的Azkaban調(diào)度系統(tǒng)，實現(xiàn)所有ETL作業(yè)的統(tǒng)一調(diào)度。
• 數(shù)據(jù)采集服務(wù)：根據(jù)數(shù)據(jù)業(yè)務(wù)需要，從網(wǎng)上或其它渠道采集數(shù)據(jù)，比如通過高德API采集POI數(shù)據(jù)等。

十二、架構(gòu)總結(jié)

通過上面的架構(gòu)設(shè)計實踐，我們總結(jié)一下實踐的經(jīng)驗，如下所示：

• 底層數(shù)據(jù)處理引擎，可能會隨著業(yè)務(wù)的發(fā)展，以及新技術(shù)的更迭，我們會有更多選擇，所以在數(shù)據(jù)處理引擎之上，設(shè)計一層REST服務(wù)，實現(xiàn)上層應(yīng)用與底層數(shù)據(jù)處理引擎解耦和。
• 多個相對較重的服務(wù)，如業(yè)務(wù)作業(yè)調(diào)度平臺、任務(wù)協(xié)調(diào)計算平臺，它們之間通過消息解耦和，能更好的降低各個服務(wù)的復(fù)雜性，以及因為變更對雙方造成的影響。
• 系統(tǒng)架構(gòu)分解，要考慮將有狀態(tài)和無狀態(tài)的部分分離，甚至在某個服務(wù)中，也有必要將有狀態(tài)和無狀態(tài)的部分進行分離。
• 業(yè)務(wù)部分和非業(yè)務(wù)部分的分離，這樣能夠適應(yīng)業(yè)務(wù)需求的變更，持續(xù)對業(yè)務(wù)部分進行更新升級，而非業(yè)務(wù)部分可能是相對穩(wěn)定的。

對于無狀態(tài)的服務(wù)，我們可以通過冗余部署多個服務(wù)實例，再通過反向代理的方式實現(xiàn)服務(wù)的高可用，甚至在演進為微服務(wù)架構(gòu)時也比較容易做到。對于有狀態(tài)的服務(wù)，因為單個服務(wù)需要維護狀態(tài)新，所以實現(xiàn)高可用的思路是，啟動多個實例，但是同一時刻只有一個是Active服務(wù)可以操作狀態(tài)，而其它實例作為Standby服務(wù)，需要通過一種機制來監(jiān)聽并發(fā)現(xiàn)Active服務(wù)的可用性，然后在其失敗時能切換到Standby服務(wù)，比如常用的Zookeeper等。