如何在髮型不亂的前提下應對單日十億計Web請求

原文地址：http://developer.51cto.com/art/201502/464640.htm

就在不久以前，AppLovin移動廣告平臺的單一廣告請求數量突破了200億大關——至關於每一秒鐘處理50萬項事務——其如火如荼的發展態勢幫助衆多品牌在激勵現有客戶的同時、從市場中拉攏到了新的買家。那麼AppLovin是如何打造出這樣一套有能力應對數百億請求、但又無需對硬件及運維人員進行顯著擴張的基礎設施的呢？

在今天的文章中，咱們將共同瞭解該公司如何發現並選擇採用各種最佳實踐，從而經過技術堆棧進化實現業務規模拓展。

極具成本效率的擴展思路

讓咱們首先從規模談起。對於咱們這些在AppLovin工做的傢伙來講，極具成本效率的規模擴展方案意味着可以在大幅提高負載處理能力的同時、避免硬件或者人員的線性增加。若是咱們只能經過採購雙倍的服務器設備或者將人員數量提升一倍來實現請求處理能力倍增，那麼這樣的方案根本沒什麼實際意義。因爲咱們在構建基礎設施時充分考慮到效率拓展需求，所以纔可以在過去一年中將服務器的請求處理數量增長到此前的二十倍。

 

 

另外一項值得注意的重點在於，對於大規模分佈式系統而言，市面上並無現成的解決方案可供借鑑。這類系統的構建工做必須使用自定義組件。不管歸屬於哪一個行業，技術團隊在創建分佈式系統時都須要對選定的組件進行認真評估。除此以外，每一次出現工做負載爆炸式增加的時候，這些組件也須要及時做出調整。

針對這些調整制定規劃意味着基礎設施自身必須擁有出色的靈活性。咱們從業務創建之初就充分意識到，移動廣告領域能夠說瞬息萬變，而咱們則須要打造一套可以與之相匹配且相適應的靈活基礎設施。咱們但願本身的這套基礎設施可以容許員工針對各種市場需求實現對應的創新活動。舉例來講，若是咱們須要進行細節調整，那麼只需在現有基礎設施之上直接實施便可、而無需對設施總體進行從新設計。這就是咱們工做的核心指導思想。

這套方案也切實帶來了回報。咱們最近剛剛將單月信息流量提高了一倍，而讓這一切變成現實的正是咱們這套靈活性出衆的基礎設施。

適應性強且具有可擴展能力的實時基礎設施

考慮到上述構建要求，咱們所打造的基礎設施堆棧中包含Web服務器、一套實時緩存層、數據庫、分佈式消息服務以及大規模並行計算系統。

做爲前端的是成百上千臺Web服務器。這些服務器設備用於應答天天來自海量用戶的數十億請求。當每一條請求傳入時，咱們須要馬上做出一系列決定，包括是否對其做出應答、爲其支付多少成本以及提供哪條廣告做爲宣傳內容——整個決定過程大約耗時50毫秒。

接下來咱們要作的是將用戶配置信息歸入緩存，整套數據庫包含數十億擁有手機設備的用戶。這些信息須要在很段的時間週期內進入可用狀態，從而實現Web服務器的響應並決定是否爲特定廣告請求提供支持。簡而言之，咱們須要的是一套分佈式緩存層，旨在以實時方式爲所有傳入請求提供所需數據。這套緩存層中使用包括Aerospike、Redis以及Memchached在內的多套系統。

除此以外，另有大量分析、報告、數據倉庫以及數據科學功能集須要接入到不一樣類型的數據庫當中。從宏觀規模角度看，這些功能必須具有分佈式能力。爲了實現這種分佈式機制，咱們採用分佈式消息或者發佈/訂閱消息服務。分佈式消息發送機製爲咱們帶來了如下幾項關鍵優點：

·咱們可以從任何位置獲取須要的信息。

·咱們可以利用日誌文件做爲事務單元，從而處理在一秒鐘內處理數以十萬計請求。

·咱們可以爲任何服務訂閱方案提供其須要的信息。

上述消息必須被髮布到全球世界內的任何位置。其目標位置多是一套惠普Vertica數據倉庫、MySQL數據庫、Apache Hadoop系統或者一套Apache Storm實時處理系統。分佈式消息發送機制能夠說是全部實時架構的核心組成部分。

最後，咱們須要利用分佈式計算體系實現數據處理。擁有分佈式計算體系意味着對Hadoop或者Apache Spark等技術方案的運用——這類並行處理系統可以查看所有數據並經過擴展處理規模龐大的數據負載。

以上列出的全部部件都經過一套分佈式日誌架構實現對接。這類基於日誌架構的基本設計思路在於，它可以接納多種數據源，利用日誌文件做爲事務單元並獲取來自所有數據源的信息。舉例來講，一臺廣告服務器可能會記錄下「我是否提供了廣告內容？用戶是否點擊過廣告內容？我是否感知到事務處理？」這一切都將被寫入日誌當中，而大量日誌信息則匯聚成消息系統。這些日誌不斷傳輸、接受處理，最後的彙總數據則被寫入數據庫。所有此類數據都可以爲日誌記錄系統所調用，並以訂閱方式交付給任何須要這些數據的服務。

這種架構類型之因此可以實現創新，是由於咱們徹底能夠將任何組件插入到系統當中。你們可能須要在特定位置插入Aerospike實時數據庫，也可能但願在其它位置使用Vertica。咱們必須有能力將所有輸入信息交付給所有不一樣類型的處理工具。擁有這樣一套基於日誌的架構可以幫助咱們經過日誌將全部數據源同集中式日誌記錄系統對接起來，並最終成爲實時訂閱系統的實現基礎。

評估技術選項

對咱們這套平臺的評估工做可以充分展現，爲何擁有具有高度靈活性的基礎設施是如此重要。

咱們最初其實選擇了利用PHP語言進行平臺構建。這是一種效率極高的開發方式，並且也很容易找到大量熟悉此類開發任務的編程人員。一樣的道理也適用於MySQL，而考慮到MongoDB做爲NoSQL數據庫領域重要成員的崇高地位，咱們決定將兩者並行使用。固然，做爲一家初創企業，咱們在起步階段在Amazon Web Services上構建起平臺的核心主體。但最後，咱們利用RabbitMQ來實現本身的發佈/訂閱消息機制。

隨着時間的推移，咱們已經開始將數據遷移到由Aerospike、Redis、Apache Cassandra、Vertica以及Hadoop系統所共同構成的綜合體系當中。咱們完成了由PHP向C++的轉換，並且將消息發佈任務由RabbiMQ轉換到一套定製化Java系統當中。與此同時，咱們還成功削減了其它系統的使用數量，將其規模嚴格控制在咱們相對易於理解、而工程技術團隊又明白該如何處理的程度上。

新軟件的引進無疑是個成本昂貴的命題。不管是開源軟件仍是專有許可軟件，若是你們做出了嘗試但卻沒能收到預期中的效果，那麼整個工做就又得退回幾個月以前。所以咱們認真對每款產品進行了評估，但願能預先了解其是否物有所值。

咱們採起的第一項舉措是審視行業中的其它廠商在使用哪些產品，這些產品又能給咱們的現有用例帶來哪些改進。舉例來講，當評估Aerospike時，來自另外一家廣告技術企業的工做人員就向咱們介紹了他的經驗。咱們以後又與4、五家其它Aerospike客戶進行了溝通，並提出「大家的用例跟咱們的是否存在類似之處？大家喜歡Aerospike的實際表現嗎？大家對Aerospike還有哪些不滿？」等問題。在此以後，咱們還很是關心「若是我將其引入本身的業務體系，是否會還出現什麼意想不到的計劃外情況？」

另外一項評估元素則源自開發人員的偏好傾向。這一點在開源項目當中表現得尤其突出，不過在商業產品範疇內也極具指導意義。與此相關的問題包括：「是否已經有開發人員編寫、使用以及爲其建立文檔？這款產品是否擁有咱們想要的發展軌跡？我身邊的朋友中是否有人正在使用這套系統？若是這是一套開源系統，那我是否須要獨力解決本身面臨的問題？」

舉例來講，咱們目前正在對Apache Storm與Apache Spark進行全面比較。這兩個項目都可以做爲實時計算處理系統的實用性解決手段，那麼哪種更受開發人員的青睞呢？在其它因素旗鼓至關的狀況下，這一點就顯得很是重要了。

接下來是適應性水平。換句話來講：這套方案可否順暢融入個人系統？舉例而言，若是咱們目前所使用的是PHP、Python或者C++，那麼這款新軟件可否以原生方式集成到對應語言當中？咱們又是否可以編寫出切實與該組件內API相對接的工具？

除此以外，咱們還要深刻考量產品出現故障的可能性。特別是在咱們的實際案例當中，企業的多座數據中心分佈在全球各個位置，最重要的就是在故障出現時及時瞭解實際狀況。某些產品在遭遇意外時不會發出警報做爲提醒，這在咱們眼中就顯得很是危險。

最後一個須要考慮的問題在於平臺的潛在風險——投入大量資源構建起的方案有可能在後續使用過程當中給企業帶來恐怖的額外成本。舉例來講，若是一家企業並無以.Net爲核心構建業務體系的經驗，那麼選擇任何一套與.Net相關的技術平臺都將毫無心義。若是這套技術方案基於Java所打造，那麼咱們是否擁有對其加以妥善維護的必要資源？若是咱們採用的是Amazon Web Services或者Google Compute Engine，那麼是否有信心在將來三年內繼續將所有業務依賴於這些雲平臺的發展趨勢？

一家企業所採用的技術方案在潛在客戶、合做夥伴或者投資者眼中每每會被視爲優點或者劣勢因素。總而言之，平臺的實施目標在於貼合業務的運營目標，這也應該成爲指導咱們選擇的根本性原則。

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