就在不久之前，AppLovin移動(dòng)廣告平臺(tái)的單一廣告請(qǐng)求數(shù)量突破了200億大關(guān)——相當(dāng)于每一秒鐘處理50萬(wàn)項(xiàng)事務(wù)——其如火如荼的發(fā)展態(tài)勢(shì)幫助眾多品牌在激勵(lì)現(xiàn)有客戶的同時(shí)、從市場(chǎng)中拉攏到了新的買(mǎi)家。那么AppLovin是如何打造出這樣一套有能力應(yīng)對(duì)數(shù)百億請(qǐng)求、但又無(wú)需對(duì)硬件及運(yùn)維人員進(jìn)行顯著擴(kuò)張的基礎(chǔ)設(shè)施的呢？

在今天的文章中，我們將共同了解該公司如何發(fā)現(xiàn)并選擇采用各類(lèi)***實(shí)踐，從而通過(guò)技術(shù)堆棧進(jìn)化實(shí)現(xiàn)業(yè)務(wù)規(guī)模拓展。

***成本效率的擴(kuò)展思路

讓我們首先從規(guī)模談起。對(duì)于我們這些在AppLovin工作的家伙來(lái)說(shuō)，***成本效率的規(guī)模擴(kuò)展方案意味著能夠在大幅提升負(fù)載處理能力的同時(shí)、避免硬件或者人員的線性增長(zhǎng)。如果我們只能通過(guò)采購(gòu)雙倍的服務(wù)器設(shè)備或者將人員數(shù)量提高一倍來(lái)實(shí)現(xiàn)請(qǐng)求處理能力倍增，那么這樣的方案根本沒(méi)什么實(shí)際意義。由于我們?cè)跇?gòu)建基礎(chǔ)設(shè)施時(shí)充分考慮到效率拓展需求，因此才能夠在過(guò)去一年中將服務(wù)器的請(qǐng)求處理數(shù)量增加到此前的二十倍。

另一項(xiàng)值得注意的重點(diǎn)在于，對(duì)于大規(guī)模分布式系統(tǒng)而言，市面上并沒(méi)有現(xiàn)成的解決方案可供借鑒。這類(lèi)系統(tǒng)的構(gòu)建工作必須使用自定義組件。無(wú)論歸屬于哪個(gè)行業(yè)，技術(shù)團(tuán)隊(duì)在建立分布式系統(tǒng)時(shí)都需要對(duì)選定的組件進(jìn)行認(rèn)真評(píng)估。除此之外，每一次出現(xiàn)工作負(fù)載爆炸式增長(zhǎng)的時(shí)候，這些組件也需要及時(shí)作出調(diào)整。

針對(duì)這些調(diào)整制定規(guī)劃意味著基礎(chǔ)設(shè)施自身必須擁有出色的靈活性。我們從業(yè)務(wù)建立之初就充分意識(shí)到，移動(dòng)廣告領(lǐng)域可以說(shuō)瞬息萬(wàn)變，而我們則需要打造一套能夠與之相匹配且相適應(yīng)的靈活基礎(chǔ)設(shè)施。我們希望自己的這套基礎(chǔ)設(shè)施能夠允許員工針對(duì)各類(lèi)市場(chǎng)需求實(shí)現(xiàn)對(duì)應(yīng)的創(chuàng)新活動(dòng)。舉例來(lái)說(shuō)，如果我們需要進(jìn)行細(xì)節(jié)調(diào)整，那么只需在現(xiàn)有基礎(chǔ)設(shè)施之上直接實(shí)施即可、而無(wú)需對(duì)設(shè)施整體進(jìn)行重新設(shè)計(jì)。這就是我們工作的核心指導(dǎo)思想。

這套方案也切實(shí)帶來(lái)了回報(bào)。我們最近剛剛將單月信息流量提升了一倍，而讓這一切變成現(xiàn)實(shí)的正是我們這套靈活性出眾的基礎(chǔ)設(shè)施。

適應(yīng)性強(qiáng)且具備可擴(kuò)展能力的實(shí)時(shí)基礎(chǔ)設(shè)施

考慮到上述構(gòu)建要求，我們所打造的基礎(chǔ)設(shè)施堆棧中包含Web服務(wù)器、一套實(shí)時(shí)緩存層、數(shù)據(jù)庫(kù)、分布式消息服務(wù)以及大規(guī)模并行計(jì)算系統(tǒng)。

作為前端的是成百上千臺(tái)Web服務(wù)器。這些服務(wù)器設(shè)備用于應(yīng)答每天來(lái)自海量用戶的數(shù)十億請(qǐng)求。當(dāng)每一條請(qǐng)求傳入時(shí)，我們需要立刻作出一系列決定，包括是否對(duì)其作出應(yīng)答、為其支付多少成本以及提供哪條廣告作為宣傳內(nèi)容——整個(gè)決定過(guò)程大約耗時(shí)50毫秒。

接下來(lái)我們要做的是將用戶配置信息納入緩存，整套數(shù)據(jù)庫(kù)包含數(shù)十億擁有手機(jī)設(shè)備的用戶。這些信息需要在很段的時(shí)間周期內(nèi)進(jìn)入可用狀態(tài)，從而實(shí)現(xiàn)Web服務(wù)器的響應(yīng)并決定是否為特定廣告請(qǐng)求提供支持。簡(jiǎn)而言之，我們需要的是一套分布式緩存層，旨在以實(shí)時(shí)方式為全部傳入請(qǐng)求提供所需數(shù)據(jù)。這套緩存層中使用包括Aerospike、Redis以及Memchached在內(nèi)的多套系統(tǒng)。

除此之外，另有大量分析、報(bào)告、數(shù)據(jù)倉(cāng)庫(kù)以及數(shù)據(jù)科學(xué)功能集需要接入到不同類(lèi)型的數(shù)據(jù)庫(kù)當(dāng)中。從宏觀規(guī)模角度看，這些功能必須具備分布式能力。為了實(shí)現(xiàn)這種分布式機(jī)制，我們采用分布式消息或者發(fā)布/訂閱消息服務(wù)。分布式消息發(fā)送機(jī)制為我們帶來(lái)了以下幾項(xiàng)關(guān)鍵優(yōu)勢(shì)：

·我們能夠從任何位置獲取需要的信息。

·我們能夠利用日志文件作為事務(wù)單元，從而處理在一秒鐘內(nèi)處理數(shù)以十萬(wàn)計(jì)請(qǐng)求。

·我們能夠?yàn)槿魏畏?wù)訂閱方案提供其需要的信息。

上述消息必須被發(fā)布到全球世界內(nèi)的任何位置。其目標(biāo)位置可能是一套惠普Vertica數(shù)據(jù)倉(cāng)庫(kù)、MySQL數(shù)據(jù)庫(kù)、Apache Hadoop系統(tǒng)或者一套Apache Storm實(shí)時(shí)處理系統(tǒng)。分布式消息發(fā)送機(jī)制可以說(shuō)是所有實(shí)時(shí)架構(gòu)的核心組成部分。

***，我們需要利用分布式計(jì)算體系實(shí)現(xiàn)數(shù)據(jù)處理。擁有分布式計(jì)算體系意味著對(duì)Hadoop或者Apache Spark等技術(shù)方案的運(yùn)用——這類(lèi)并行處理系統(tǒng)能夠查看全部數(shù)據(jù)并通過(guò)擴(kuò)展處理規(guī)模龐大的數(shù)據(jù)負(fù)載。

以上列出的所有部件都通過(guò)一套分布式日志架構(gòu)實(shí)現(xiàn)對(duì)接。這類(lèi)基于日志架構(gòu)的基本設(shè)計(jì)思路在于，它能夠接納多種數(shù)據(jù)源，利用日志文件作為事務(wù)單元并獲取來(lái)自全部數(shù)據(jù)源的信息。舉例來(lái)說(shuō)，一臺(tái)廣告服務(wù)器可能會(huì)記錄下“我是否提供了廣告內(nèi)容？用戶是否點(diǎn)擊過(guò)廣告內(nèi)容？我是否感知到事務(wù)處理？”這一切都將被寫(xiě)入日志當(dāng)中，而大量日志信息則匯聚成消息系統(tǒng)。這些日志不斷傳輸、接受處理，***的匯總數(shù)據(jù)則被寫(xiě)入數(shù)據(jù)庫(kù)。全部此類(lèi)數(shù)據(jù)都能夠?yàn)槿罩居涗浵到y(tǒng)所調(diào)用，并以訂閱方式交付給任何需要這些數(shù)據(jù)的服務(wù)。

這種架構(gòu)類(lèi)型之所以能夠?qū)崿F(xiàn)創(chuàng)新，是因?yàn)槲覀兺耆梢詫⑷魏谓M件插入到系統(tǒng)當(dāng)中。大家可能需要在特定位置插入Aerospike實(shí)時(shí)數(shù)據(jù)庫(kù)，也可能希望在其它位置使用Vertica。我們必須有能力將全部輸入信息交付給全部不同類(lèi)型的處理工具。擁有這樣一套基于日志的架構(gòu)能夠幫助我們通過(guò)日志將所有數(shù)據(jù)源同集中式日志記錄系統(tǒng)對(duì)接起來(lái)，并最終成為實(shí)時(shí)訂閱系統(tǒng)的實(shí)現(xiàn)基礎(chǔ)。

評(píng)估技術(shù)選項(xiàng)

對(duì)我們這套平臺(tái)的評(píng)估工作能夠充分展示，為什么擁有具備高度靈活性的基礎(chǔ)設(shè)施是如此重要。

我們最初其實(shí)選擇了利用PHP語(yǔ)言進(jìn)行平臺(tái)構(gòu)建。這是一種效率極高的開(kāi)發(fā)方式，而且也很容易找到大量熟悉此類(lèi)開(kāi)發(fā)任務(wù)的編程人員。同樣的道理也適用于MySQL，而考慮到MongoDB作為NoSQL數(shù)據(jù)庫(kù)領(lǐng)域重要成員的崇高地位，我們決定將二者并行使用。當(dāng)然，作為一家初創(chuàng)企業(yè)，我們?cè)谄鸩诫A段在Amazon Web Services上構(gòu)建起平臺(tái)的核心主體。但***，我們利用RabbitMQ來(lái)實(shí)現(xiàn)自己的發(fā)布/訂閱消息機(jī)制。

隨著時(shí)間的推移，我們已經(jīng)開(kāi)始將數(shù)據(jù)遷移到由Aerospike、Redis、Apache Cassandra、Vertica以及Hadoop系統(tǒng)所共同構(gòu)成的綜合體系當(dāng)中。我們完成了由PHP向C++的轉(zhuǎn)換，而且將消息發(fā)布任務(wù)由RabbiMQ轉(zhuǎn)換到一套定制化Java系統(tǒng)當(dāng)中。與此同時(shí)，我們還成功削減了其它系統(tǒng)的使用數(shù)量，將其規(guī)模嚴(yán)格控制在我們相對(duì)易于理解、而工程技術(shù)團(tuán)隊(duì)又明白該如何處理的程度上。

新軟件的引進(jìn)無(wú)疑是個(gè)成本昂貴的命題。無(wú)論是開(kāi)源軟件還是專有許可軟件，如果大家作出了嘗試但卻沒(méi)能收到預(yù)期中的效果，那么整個(gè)工作就又得退回幾個(gè)月之前。因此我們認(rèn)真對(duì)每款產(chǎn)品進(jìn)行了評(píng)估，希望能預(yù)先了解其是否物有所值。

我們采取的***項(xiàng)舉措是審視行業(yè)中的其它廠商在使用哪些產(chǎn)品，這些產(chǎn)品又能給我們的現(xiàn)有用例帶來(lái)哪些改進(jìn)。舉例來(lái)說(shuō)，當(dāng)評(píng)估Aerospike時(shí)，來(lái)自另一家廣告技術(shù)企業(yè)的工作人員就向我們介紹了他的經(jīng)驗(yàn)。我們之后又與四、五家其它Aerospike客戶進(jìn)行了溝通，并提出“你們的用例跟我們的是否存在相似之處？你們喜歡Aerospike的實(shí)際表現(xiàn)嗎？你們對(duì)Aerospike還有哪些不滿？”等問(wèn)題。在此之后，我們還非常關(guān)心“如果我將其引入自己的業(yè)務(wù)體系，是否會(huì)還出現(xiàn)什么意想不到的計(jì)劃外狀況？”

另一項(xiàng)評(píng)估元素則源自開(kāi)發(fā)人員的偏好傾向。這一點(diǎn)在開(kāi)源項(xiàng)目當(dāng)中表現(xiàn)得尤為突出，不過(guò)在商業(yè)產(chǎn)品范疇內(nèi)也***指導(dǎo)意義。與此相關(guān)的問(wèn)題包括：“是否已經(jīng)有開(kāi)發(fā)人員編寫(xiě)、使用以及為其創(chuàng)建文檔？這款產(chǎn)品是否擁有我們想要的發(fā)展軌跡？我身邊的朋友中是否有人正在使用這套系統(tǒng)？如果這是一套開(kāi)源系統(tǒng)，那我是否需要獨(dú)力解決自己面臨的問(wèn)題？”

舉例來(lái)說(shuō)，我們目前正在對(duì)Apache Storm與Apache Spark進(jìn)行全面比較。這兩個(gè)項(xiàng)目都能夠作為實(shí)時(shí)計(jì)算處理系統(tǒng)的實(shí)用性解決手段，那么哪一種更受開(kāi)發(fā)人員的青睞呢？在其它因素旗鼓相當(dāng)?shù)那闆r下，這一點(diǎn)就顯得非常重要了。

接下來(lái)是適應(yīng)性水平。換句話來(lái)說(shuō)：這套方案能否順暢融入我的系統(tǒng)？舉例而言，如果我們目前所使用的是PHP、Python或者C++，那么這款新軟件能否以原生方式集成到對(duì)應(yīng)語(yǔ)言當(dāng)中？我們又是否能夠編寫(xiě)出切實(shí)與該組件內(nèi)API相對(duì)接的工具？

除此之外，我們還要深入考量產(chǎn)品出現(xiàn)故障的可能性。特別是在我們的實(shí)際案例當(dāng)中，企業(yè)的多座數(shù)據(jù)中心分布在全球各個(gè)位置，最重要的就是在故障出現(xiàn)時(shí)及時(shí)了解實(shí)際情況。某些產(chǎn)品在遭遇意外時(shí)不會(huì)發(fā)出警報(bào)作為提醒，這在我們眼中就顯得非常危險(xiǎn)。

***一個(gè)需要考慮的問(wèn)題在于平臺(tái)的潛在風(fēng)險(xiǎn)——投入大量資源構(gòu)建起的方案有可能在后續(xù)使用過(guò)程中給企業(yè)帶來(lái)恐怖的額外成本。舉例來(lái)說(shuō)，如果一家企業(yè)并沒(méi)有以.Net為核心構(gòu)建業(yè)務(wù)體系的經(jīng)驗(yàn)，那么選擇任何一套與.Net相關(guān)的技術(shù)平臺(tái)都將毫無(wú)意義。如果這套技術(shù)方案基于Java所打造，那么我們是否擁有對(duì)其加以妥善維護(hù)的必要資源？如果我們采用的是Amazon Web Services或者Google Compute Engine，那么是否有信心在未來(lái)三年內(nèi)繼續(xù)將全部業(yè)務(wù)依賴于這些云平臺(tái)的發(fā)展趨勢(shì)？

一家企業(yè)所采用的技術(shù)方案在潛在客戶、合作伙伴或者投資者眼中往往會(huì)被視為優(yōu)勢(shì)或者劣勢(shì)因素?？偠灾脚_(tái)的實(shí)施目標(biāo)在于貼合業(yè)務(wù)的運(yùn)營(yíng)目標(biāo)，這也應(yīng)該成為指導(dǎo)我們選擇的根本性原則。

英文：http://www.infoworld.com/article/2868513/database/how-to-serve-billion-web-requests-per-day.html