本文來(lái)自攜程技術(shù)中心基礎(chǔ)業(yè)務(wù)研發(fā)部的《應(yīng)用架構(gòu)涅槃》系列分享。據(jù)基礎(chǔ)業(yè)務(wù)研發(fā)部負(fù)責(zé)人李小林介紹，互聯(lián)網(wǎng)二次革命的移動(dòng)互聯(lián)網(wǎng)時(shí)代，如何吸引用戶、留住用戶并深入挖掘用戶價(jià)值，在激烈的競(jìng)爭(zhēng)中脫穎而出，是各大電商的重要課題。通過各類大數(shù)據(jù)對(duì)用戶進(jìn)行研究，以數(shù)據(jù)驅(qū)動(dòng)產(chǎn)品是解決這個(gè)課題的主要手段，攜程的大數(shù)據(jù)團(tuán)隊(duì)也由此應(yīng)運(yùn)而生;經(jīng)過幾年的努力，大數(shù)據(jù)的相關(guān)技術(shù)為業(yè)務(wù)帶來(lái)了驚人的提升與幫助。以基礎(chǔ)大數(shù)據(jù)的用戶意圖服務(wù)為例，通過將廣告和欄位的“千人一面”變?yōu)?ldquo;千人千面”，在提升用戶便捷性，可用性，降低費(fèi)力度的同時(shí)，其轉(zhuǎn)化率也得到了數(shù)倍的提升，體現(xiàn)了大數(shù)據(jù)服務(wù)的真正價(jià)值。

在李小林看來(lái)，大數(shù)據(jù)是互聯(lián)網(wǎng)行業(yè)發(fā)展的趨勢(shì)，互聯(lián)網(wǎng)的從業(yè)人員需要高度關(guān)注大數(shù)據(jù)相關(guān)的技術(shù)及應(yīng)用，也希望通過這一系列大數(shù)據(jù)相關(guān)的講座，讓各位同學(xué)有所收獲。

首場(chǎng)《應(yīng)用架構(gòu)涅磐》分享來(lái)自基礎(chǔ)業(yè)務(wù)研發(fā)部的董銳，包括業(yè)務(wù)高速發(fā)展帶來(lái)的應(yīng)用架構(gòu)挑戰(zhàn)、應(yīng)對(duì)挑戰(zhàn)的架構(gòu)涅磐、應(yīng)用系統(tǒng)整體架構(gòu)和推薦系統(tǒng)案例等四個(gè)部分。

一、業(yè)務(wù)高速發(fā)展帶來(lái)的應(yīng)用架構(gòu)挑戰(zhàn)

公司業(yè)務(wù)高速發(fā)展帶來(lái)哪些主要的變化，以及給我們的系統(tǒng)帶來(lái)了哪些挑戰(zhàn)?

業(yè)務(wù)需求的急速增長(zhǎng)，訪問請(qǐng)求的并發(fā)量激增，2016年1月份以來(lái)，業(yè)務(wù)部門的服務(wù)日均請(qǐng)求量激增了5.5倍。

業(yè)務(wù)邏輯日益復(fù)雜化，基礎(chǔ)業(yè)務(wù)研發(fā)部需要支撐起OTA數(shù)十個(gè)業(yè)務(wù)線，業(yè)務(wù)邏輯日趨復(fù)雜和繁多。

業(yè)務(wù)數(shù)據(jù)源多樣化，異構(gòu)化，接入的業(yè)務(wù)線、合作公司的數(shù)據(jù)源越來(lái)越多;接入的數(shù)據(jù)結(jié)構(gòu)由以前的數(shù)據(jù)庫(kù)結(jié)構(gòu)化數(shù)據(jù)整合轉(zhuǎn)為Hive表、評(píng)論文本數(shù)據(jù)、日志數(shù)據(jù)、天氣數(shù)據(jù)、網(wǎng)頁(yè)數(shù)據(jù)等多元化異構(gòu)數(shù)據(jù)整合。

業(yè)務(wù)的高速發(fā)展和迭代，部門一直以追求以最少的開發(fā)人力，以架構(gòu)和系統(tǒng)的技術(shù)優(yōu)化，支撐起攜程各業(yè)務(wù)線高速發(fā)展和迭代的需要。

在這種新形勢(shì)下，傳統(tǒng)應(yīng)用架構(gòu)不得不變，做為工程師也必然要自我涅槃，改為大數(shù)據(jù)及新的高并發(fā)架構(gòu)，來(lái)應(yīng)對(duì)業(yè)務(wù)需求激增及高速迭代的需要。計(jì)算分層分解、去SQL、去數(shù)據(jù)庫(kù)化、模塊化拆解的相關(guān)技改工作已經(jīng)刻不容緩。

以用戶意圖(AI 點(diǎn)金杖)的個(gè)性化服務(wù)為例， 面對(duì)BU業(yè)務(wù)線的全面支持的迫切需要，其應(yīng)用架構(gòu)必須解決如下技術(shù)難點(diǎn)：

高訪問并發(fā)：每天近億次的訪問請(qǐng)求;

數(shù)據(jù)量大：每天TB級(jí)的增量數(shù)據(jù)，近百億條的用戶數(shù)據(jù)，上百萬(wàn)的產(chǎn)品數(shù)據(jù);

業(yè)務(wù)邏輯復(fù)雜：復(fù)雜個(gè)性化算法和LBS算法;例如：滿足一個(gè)復(fù)雜用戶請(qǐng)求需要大量計(jì)算和30次左右的SQL數(shù)據(jù)查詢，服務(wù)延時(shí)越來(lái)越長(zhǎng);

高速迭代上線：面對(duì)OTA多業(yè)務(wù)線的個(gè)性化、Cross-saling、Up-saling、需滿足提升轉(zhuǎn)化率的迫切需求，迭代欄位或場(chǎng)景要快速，同時(shí)減少研發(fā)成本。

二、應(yīng)對(duì)挑戰(zhàn)的架構(gòu)涅磐

面對(duì)這些挑戰(zhàn)，我們的應(yīng)用系統(tǒng)架構(gòu)應(yīng)該如何涅磐?主要分如下三大方面系統(tǒng)詳解:

存儲(chǔ)的涅磐，這一點(diǎn)對(duì)于整個(gè)系統(tǒng)的吞吐量和并發(fā)量的提升起到最關(guān)鍵的作用，需要結(jié)合數(shù)據(jù)存儲(chǔ)模型和具體應(yīng)用的場(chǎng)景。

計(jì)算的涅磐，可以從橫向和縱向考慮：橫向主要是增加并發(fā)度，首先想到的是分布式。縱向拆分就是要求我們找到計(jì)算的結(jié)合點(diǎn)從而進(jìn)行分層，針對(duì)不同的層次選擇不同的計(jì)算地點(diǎn)。然后再將各層次計(jì)算完后的結(jié)果相結(jié)合，盡可能最大化系統(tǒng)整體的處理能力。

業(yè)務(wù)層架構(gòu)的涅磐，要求系統(tǒng)的良好的模塊化設(shè)計(jì)，清楚的定義模塊的邊界，模塊自升級(jí)和可配置化。

三、應(yīng)用系統(tǒng)的整體架構(gòu)

認(rèn)識(shí)到需要應(yīng)對(duì)的挑戰(zhàn)，我們應(yīng)該如何設(shè)計(jì)我們的系統(tǒng)呢，下面將全面的介紹下我們的應(yīng)用系統(tǒng)整體架構(gòu)。

下圖就是我們應(yīng)用系統(tǒng)整體架構(gòu)以及系統(tǒng)層次的模塊構(gòu)成。

數(shù)據(jù)源部分，Hermes是攜程框架部門提供的消息隊(duì)列，基于Kafka和MySQL做為底層實(shí)現(xiàn)的封裝，應(yīng)用于系統(tǒng)間實(shí)時(shí)數(shù)據(jù)傳輸交互通道。Hive和HDFS是攜程海量數(shù)據(jù)的主要存儲(chǔ)，兩者來(lái)自Hadoop生態(tài)體系。Hadoop大家已經(jīng)很熟悉，如果不熟悉的同學(xué)只要知道Hadoop主要用于大數(shù)據(jù)量存儲(chǔ)和并行計(jì)算批處理工作。

Hive是基于Hadoop平臺(tái)的數(shù)據(jù)倉(cāng)庫(kù)，沿用了關(guān)系型數(shù)據(jù)庫(kù)的很多概念。比如說(shuō)數(shù)據(jù)庫(kù)和表，還有一套近似于SQL的查詢接口的支持，在Hive里叫做HQL，但是其底層的實(shí)現(xiàn)細(xì)節(jié)和關(guān)系型數(shù)據(jù)庫(kù)完全不一樣，Hive底層所有的計(jì)算都是基于MR來(lái)完成，我們的數(shù)據(jù)工程師90%都數(shù)據(jù)處理工作都基于它來(lái)完成。

離線部分，包含的模塊有MR、Hive、Mahout、SparkQL/MLLib。Hive上面已經(jīng)介紹過，Mahout簡(jiǎn)單理解提供基于Hadoop平臺(tái)進(jìn)行數(shù)據(jù)挖掘的一些機(jī)器學(xué)習(xí)的算法包。Spark類似hadoop也是提供大數(shù)據(jù)并行批量處理平臺(tái)，但是它是基于內(nèi)存的。SparkQL 和Spark MLLib是基于Spark平臺(tái)的SQL查詢引擎和數(shù)據(jù)挖掘相關(guān)算法框架。我們主要用Mahout和Spark MLLib進(jìn)行數(shù)據(jù)挖掘工作。

調(diào)度系統(tǒng)zeus，是淘寶開源大數(shù)據(jù)平臺(tái)調(diào)度系統(tǒng)，于2015年引進(jìn)到攜程，之后我們進(jìn)行了重構(gòu)和功能升級(jí)，做為攜程大數(shù)據(jù)平臺(tái)的作業(yè)調(diào)度平臺(tái)。

近線部分，是基于Muise來(lái)實(shí)現(xiàn)我們的近實(shí)時(shí)的計(jì)算場(chǎng)景，Muise是也是攜程OPS提供的實(shí)時(shí)計(jì)算流處理平臺(tái)，內(nèi)部是基于Storm實(shí)現(xiàn)與HERMES消息隊(duì)列搭配起來(lái)使用。例如，我們使用MUSIE通過消費(fèi)來(lái)自消息隊(duì)列里的用戶實(shí)時(shí)行為，訂單記錄，結(jié)合畫像等一起基礎(chǔ)數(shù)據(jù)，經(jīng)一系列復(fù)雜的規(guī)則和算法，實(shí)時(shí)的識(shí)別出用戶的行程意圖。

后臺(tái)/線上應(yīng)用部分，MySQL用于支撐后臺(tái)系統(tǒng)的數(shù)據(jù)庫(kù)。ElasticSearch是基于Lucene實(shí)現(xiàn)的分布式搜索引擎，用于索引用戶畫像的數(shù)據(jù)，支持離線精準(zhǔn)營(yíng)銷的用戶篩選，同時(shí)支持線上應(yīng)用推薦系統(tǒng)的選品功能。HBase 基于Hadoop的HDFS 上的列存儲(chǔ)NoSQL數(shù)據(jù)庫(kù)，用于后臺(tái)報(bào)表可視化系統(tǒng)和線上服務(wù)的數(shù)據(jù)存儲(chǔ)。

這里說(shuō)明一下, 在線和后臺(tái)應(yīng)用使用的ElasticSearch和HBase集群是分開的，互不影響。Redis支持在線服務(wù)的高速緩存，用于緩存統(tǒng)計(jì)分析出來(lái)的熱點(diǎn)數(shù)據(jù)。

四、推薦系統(tǒng)案例

介紹完我們應(yīng)用系統(tǒng)的整體構(gòu)成，接下來(lái)分享基于這套系統(tǒng)架構(gòu)實(shí)現(xiàn)的一個(gè)實(shí)例——攜程個(gè)性化推薦系統(tǒng)。

推薦系統(tǒng)的架構(gòu)圖：

1、存儲(chǔ)的涅磐

1)NoSQL (HBase+Redis)

我們之前存儲(chǔ)使用的是MySQL，一般關(guān)系型數(shù)據(jù)庫(kù)會(huì)做為應(yīng)用系統(tǒng)存儲(chǔ)的首選。大家知道MySQL非商業(yè)版對(duì)分布式支持不夠，在存儲(chǔ)數(shù)據(jù)量不高，查詢量和計(jì)算復(fù)雜度不是很大的情況下，可以滿足應(yīng)用系統(tǒng)絕大部分的功能需求。

我們現(xiàn)狀是需要安全存儲(chǔ)海量的數(shù)據(jù)，高吞吐，并發(fā)能力強(qiáng)，同時(shí)隨著數(shù)據(jù)量和請(qǐng)求量的快速增加，能夠通過加節(jié)點(diǎn)來(lái)擴(kuò)容。另外還需要支持故障轉(zhuǎn)移，自動(dòng)恢復(fù)，無(wú)需額外的運(yùn)維成本。綜上幾個(gè)主要因素，我們進(jìn)行了大量的調(diào)研和測(cè)試，最終我們選用HBase和Redis兩個(gè)NoSQL數(shù)據(jù)庫(kù)來(lái)取代以往使用的MySQL。我們把用戶意圖以及推薦產(chǎn)品數(shù)據(jù)以KV的形式存儲(chǔ)在HBase中，我對(duì)操作HBase進(jìn)行一些優(yōu)化，其中包括rowkey的設(shè)計(jì)，預(yù)分配，數(shù)據(jù)壓縮等，同時(shí)針對(duì)我們的使用場(chǎng)景對(duì)HBase本身配置方面的也進(jìn)行了調(diào)優(yōu)。目前存儲(chǔ)的數(shù)據(jù)量已經(jīng)達(dá)到TB級(jí)別，支持每天千萬(wàn)次請(qǐng)求，同時(shí)保證99%在50毫秒內(nèi)返回。

Redis和多數(shù)應(yīng)用系統(tǒng)使用方式一樣，主要用于緩存熱點(diǎn)數(shù)據(jù)，這里就不多說(shuō)了。

2)搜索引擎 (ElasticSearch)

ES索引各業(yè)務(wù)線產(chǎn)品特征數(shù)據(jù)，提供基于用戶的意圖特征和產(chǎn)品特征復(fù)雜的多維檢索和排序功能，當(dāng)前集群由4臺(tái)大內(nèi)存物理機(jī)器構(gòu)成，采用全內(nèi)存索引。對(duì)比某一個(gè)復(fù)雜的查詢場(chǎng)景，之前用MySQL將近需要30次查詢，使用ES只需要一次組合查詢且在100毫秒內(nèi)返回。目前每天千萬(wàn)次搜索，99%以上在300毫秒以內(nèi)返回。

2、計(jì)算的涅磐

1)數(shù)據(jù)源，我們的數(shù)據(jù)源分結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)以及非結(jié)構(gòu)化數(shù)據(jù)。

結(jié)構(gòu)化數(shù)據(jù)主要是指攜程各產(chǎn)線的產(chǎn)品維表和訂單數(shù)據(jù)，有酒店、景酒、團(tuán)隊(duì)游、門票、景點(diǎn)等，還有一些基礎(chǔ)數(shù)據(jù)，比如城市表、車站等，這類數(shù)據(jù)基本上都是T+1，每天會(huì)有流程去各BU的生產(chǎn)表拉取數(shù)據(jù)。

半結(jié)構(gòu)化數(shù)據(jù)是指，攜程用戶的訪問行為數(shù)據(jù)，例如瀏覽、搜索、預(yù)訂、反饋等，這邊順便提一下，這些數(shù)據(jù)這些是由前端采集框架實(shí)時(shí)采集，然后下發(fā)到后端的收集服務(wù)，由收集服務(wù)在寫入到Hermes消息隊(duì)列，一路會(huì)落地到Hadoop上面做長(zhǎng)期存儲(chǔ)，另一路近線層可以通過訂閱Hermes此類數(shù)據(jù)Topic進(jìn)行近實(shí)時(shí)的計(jì)算工作。

我們還用到外部合作渠道的數(shù)據(jù)，還有一些評(píng)論數(shù)據(jù)，評(píng)論屬于非結(jié)構(gòu)化的，也是T+1更新。

2)離線計(jì)算，主要分三個(gè)處理階段。

預(yù)處理階段，這塊主要為后續(xù)數(shù)據(jù)挖掘做一些數(shù)據(jù)的準(zhǔn)備工作，數(shù)據(jù)去重，過濾，對(duì)缺失信息的補(bǔ)足。舉例來(lái)說(shuō)采集下來(lái)的用戶行為數(shù)據(jù)，所含有的產(chǎn)品信息很少，我們會(huì)使用產(chǎn)品表的數(shù)據(jù)進(jìn)行一些補(bǔ)足，確保給后續(xù)的數(shù)據(jù)挖掘使用時(shí)候盡量完整的。

數(shù)據(jù)挖掘階段，主要運(yùn)用一些常用的數(shù)據(jù)挖掘算法進(jìn)行模型訓(xùn)練和推薦數(shù)據(jù)的輸出(分類、聚類、回歸、CF等)。

結(jié)果導(dǎo)入階段，我們通過可配置的數(shù)據(jù)導(dǎo)入工具將推薦數(shù)據(jù)，進(jìn)行一系列轉(zhuǎn)換后，導(dǎo)入到HBase、Redis以及建立ES索引，Redis存儲(chǔ)的是經(jīng)統(tǒng)計(jì)計(jì)算出的熱點(diǎn)數(shù)據(jù)。

3)近線計(jì)算(用戶意圖、產(chǎn)品緩存)

當(dāng)用戶沒有明確的目的性情況下，很難找到滿足興趣的產(chǎn)品，我們不僅需要了解用戶的歷史興趣，用戶實(shí)時(shí)行為特征的抽取和理解更加重要，以便快速的推薦出符合用戶當(dāng)前興趣的產(chǎn)品，這就是用戶意圖服務(wù)需要實(shí)現(xiàn)的功能。

一般來(lái)說(shuō)用戶特征分成兩大類：一種是穩(wěn)定的特征(用戶畫像)，如用戶性別、常住地、主題偏好等特征;另一類是根據(jù)用戶行為計(jì)算獲取的特征，如用戶對(duì)酒店星級(jí)的偏好、目的地偏好、跟團(tuán)游/自由行偏好等?；谇懊嫠龅挠?jì)算的特點(diǎn)，我們使用近在線計(jì)算來(lái)獲取第二類用戶特征，整體框圖如下。從圖中可以看出它的輸入數(shù)據(jù)源包括兩大類：第一類是實(shí)時(shí)的用戶行為;第二類是用戶畫像，歷史交易以及情景等離線模塊提供的數(shù)據(jù)。結(jié)合這兩類數(shù)據(jù)，經(jīng)一些列復(fù)雜的近線學(xué)習(xí)算法和規(guī)則引擎，計(jì)算得出用戶當(dāng)前實(shí)時(shí)意圖列表存儲(chǔ)到HBase和Redis中。

攜程用戶意圖框架

近線另一個(gè)工作是產(chǎn)品數(shù)據(jù)緩存，攜程的業(yè)務(wù)線很多，而我們的推薦系統(tǒng)會(huì)推各個(gè)業(yè)務(wù)線的產(chǎn)品，因此我們需要調(diào)用所有業(yè)務(wù)線的產(chǎn)品服務(wù)接口，但隨著我們上線的場(chǎng)景的增加，這樣無(wú)形的增加了對(duì)業(yè)務(wù)方接口的調(diào)用壓力。而且業(yè)務(wù)線產(chǎn)品接口服務(wù)主要應(yīng)用于業(yè)務(wù)的主流程或關(guān)鍵型應(yīng)用，比較重，且SLA服務(wù)等級(jí)層次不齊，可能會(huì)影響到整個(gè)推薦系統(tǒng)的響應(yīng)時(shí)間。

為了解決這兩個(gè)問題，我們?cè)O(shè)計(jì)了近在線計(jì)算來(lái)進(jìn)行業(yè)務(wù)的產(chǎn)品信息異步緩存策略，具體的流程如下。

我們會(huì)將待推薦的產(chǎn)品Id全部通過Kafka異步下發(fā)，在Storm中我們會(huì)對(duì)各業(yè)務(wù)方的產(chǎn)品首先進(jìn)行聚合，達(dá)到批處理個(gè)數(shù)或者時(shí)間gap時(shí)，再調(diào)用各業(yè)務(wù)方的接口，這樣減少對(duì)業(yè)務(wù)方接口的壓力。通過調(diào)用業(yè)務(wù)方接口更新的產(chǎn)品狀態(tài)臨時(shí)緩存起來(lái)(根據(jù)各業(yè)務(wù)產(chǎn)品信息更新周期分別設(shè)置緩存失效時(shí)間)，在線計(jì)算的時(shí)候直接先讀取臨時(shí)緩存數(shù)據(jù)，緩存不存在的情況下，再擊穿到業(yè)務(wù)的接口服務(wù)。

產(chǎn)品異步緩存框架

4)在線計(jì)算(2個(gè)關(guān)鍵業(yè)務(wù)層架構(gòu)模塊介紹)

①業(yè)務(wù)層架構(gòu)-數(shù)據(jù)治理和訪問模塊，支持的存儲(chǔ)介質(zhì)，目前支持的存儲(chǔ)介質(zhì)有Localcache、Redis、HBase、MySQL可以支持橫向擴(kuò)展。統(tǒng)一配置，對(duì)同一份數(shù)據(jù)，采用統(tǒng)一配置，可以隨意存儲(chǔ)在任意介質(zhì)，根據(jù)id查詢返回統(tǒng)一格式的數(shù)據(jù)，對(duì)查詢接口完全透明。

穿透策略和容災(zāi)策略，Redis只存儲(chǔ)了熱數(shù)據(jù)，當(dāng)需要查詢冷數(shù)據(jù)則可以自動(dòng)到下一級(jí)存儲(chǔ)如HBase查詢，避免緩存資源浪費(fèi)。當(dāng)Redis出現(xiàn)故障時(shí)或請(qǐng)求數(shù)異常上漲，超過整體承受能力，此時(shí)服務(wù)降級(jí)自動(dòng)生效，并可配置化。

②業(yè)務(wù)層架構(gòu)-推薦策略模塊，整個(gè)流程是先將用戶意圖、用戶瀏覽，相關(guān)推薦策略生成的產(chǎn)品集合等做為數(shù)據(jù)輸入，接著按照?qǐng)鼍耙?guī)則，業(yè)務(wù)邏輯重新過濾，聚合、排序。最后驗(yàn)證和拼裝業(yè)務(wù)線產(chǎn)品信息后輸出推薦結(jié)果;

我們對(duì)此流程每一步進(jìn)行了一些模塊化的抽象，將重排序邏輯按步驟抽象解耦，抽象如右圖所示的多個(gè)組件，開發(fā)新接口時(shí)僅需要將內(nèi)部DSL拼裝便可以得到滿足業(yè)務(wù)需求的推薦服務(wù);提高了代碼的復(fù)用率和可讀性，減少了超過50%的開發(fā)時(shí)間;對(duì)于充分驗(yàn)證的模塊的復(fù)用，有效保證了服務(wù)的質(zhì)量。

來(lái)源：極客頭條