豌豆莢作為創(chuàng)新工場的首批孵化項(xiàng)目之一，從2009年12月發(fā)展至今，用戶量已經(jīng)增長至4.1億。豌豆莢的主要業(yè)務(wù)在國內(nèi)，幫助用戶在手機(jī)上發(fā)現(xiàn)、獲取和消費(fèi)應(yīng)用、游戲、視頻、電子書、壁紙等娛樂內(nèi)容，在東南亞地區(qū)等海外市場也做了類似的業(yè)務(wù)探索。
這樣一個(gè)快速增長的系統(tǒng)，對IT的底層支持也是一個(gè)相當(dāng)大的挑戰(zhàn)。本文將介紹豌豆莢在IT基礎(chǔ)架構(gòu)、工具、流程方面做過的一些事，在不同需求之間如何平衡，團(tuán)隊(duì)職責(zé)的劃分，以及遇到的一些挑戰(zhàn)。
挑戰(zhàn)
豌豆莢創(chuàng)立初期國內(nèi)還沒有可靠的公有云服務(wù)，所以從2010年開始，豌豆莢通過自購服務(wù)器的方式，伴隨著豌豆莢在中國市場發(fā)展規(guī)模逐漸擴(kuò)大，豌豆莢已經(jīng)在國內(nèi)建成了規(guī)模較大的數(shù)據(jù)中心。2014年豌豆莢開始國際化布局，但自建數(shù)據(jù)中心的方式卻很難在國外復(fù)制。“不同國家的采購流程和管理政策都不一樣，在一些東南亞國家，甚至基礎(chǔ)網(wǎng)絡(luò)提供商都千差萬別，自建機(jī)房不僅速度緩慢而且無法控制進(jìn)度。”豌豆莢工程生產(chǎn)力部門質(zhì)量總監(jiān)高磊表示，“而業(yè)務(wù)部門又對迅速提供IT資源支持有著非常緊迫的要求，最終我們發(fā)現(xiàn)只用采用云服務(wù)才能真正解決我們的問題。”
為什么使用AWS
在決定采用云服務(wù)后，豌豆莢便確定了使用AWS，“我們的工程師團(tuán)隊(duì)和運(yùn)維人員對AWS比較熟悉，如果采用其他公有云產(chǎn)品勢必需要一個(gè)適應(yīng)和學(xué)習(xí)的過程，但我們使用AWS的學(xué)習(xí)成本很低，因此使用AWS可以說是順理成章。”質(zhì)量總監(jiān)高磊說。
除了減少團(tuán)隊(duì)的學(xué)習(xí)成本，AWS服務(wù)與自身業(yè)務(wù)的高度契合也是促使豌豆莢決定采用AWS的重要原因。通過Amazon Elastic Compute Cloud (Amazon EC2)，豌豆莢提升了新產(chǎn)品在海外的發(fā)布速度，還可以根據(jù)實(shí)際使用量確定服務(wù)器計(jì)算資源，既提升了工作效率還顯著降低了成本，而且由于Amazon EC2的高可用性架構(gòu)，也大大提升了應(yīng)用的穩(wěn)定性和可用性。此外，豌豆莢還使用Amazon ElastiCache自動檢測并調(diào)換運(yùn)行不暢的緩存節(jié)點(diǎn)，降低了基礎(chǔ)設(shè)備日常管理的費(fèi)用，同時(shí)豌豆莢也使用Amazon ElasticCache集成的Amazon CloudWatch功能對設(shè)備進(jìn)行監(jiān)控，從而更加準(zhǔn)確和清楚的了解與Redis等節(jié)點(diǎn)相關(guān)的性能指標(biāo)，保證服務(wù)和產(chǎn)品穩(wěn)定。
收益
如果豌豆莢采用傳統(tǒng)自建數(shù)據(jù)中心的形式，保守估計(jì)每個(gè)機(jī)房需要3-4個(gè)月才能完成，而在AWS上只需要幾分鐘便可以完成一切基礎(chǔ)設(shè)施的調(diào)試。更重要的一點(diǎn)，豌豆莢并沒有因?yàn)殚_始拓展海外業(yè)務(wù)增加任何運(yùn)維人員，并且與負(fù)責(zé)傳統(tǒng)數(shù)據(jù)中心的人員投入相比，管理AWS日常運(yùn)行所需要的人力幾乎可以忽略不計(jì)。在固定資本投入上，使用AWS與自建數(shù)據(jù)中心相比較，也能有一定程度的節(jié)約。不僅如此，通過對AWS收費(fèi)政策的理解不斷加深，豌豆莢也發(fā)現(xiàn)了更多降低使用成本的方法。
豌豆莢與AWS的合作處于起步階段，隨著對AWS各項(xiàng)業(yè)務(wù)的了解不斷加深，豌豆莢還將繼續(xù)將更多業(yè)務(wù)遷移至AWS上。
基礎(chǔ)設(shè)施的建設(shè)與增長
豌豆莢誕生于2009年12月，機(jī)房部署是從2010年年初開始。那時(shí)候因?yàn)檫€沒有成熟的云服務(wù)可用，所以選擇了自建機(jī)房的方案。到目前為止，豌豆莢已經(jīng)在全國各地尤其是北京、天津地區(qū)建立了多個(gè)節(jié)點(diǎn)。
從對基礎(chǔ)設(shè)施資源使用的情況來看，豌豆莢的主要業(yè)務(wù)對帶寬和 CDN 資源用量會比較高；而從單一業(yè)務(wù)來看，各類數(shù)據(jù)挖掘和分析對服務(wù)器資源的占用是最大的。豌豆莢從創(chuàng)建一開始就是數(shù)據(jù)驅(qū)動的業(yè)務(wù)，有很強(qiáng)的用戶行為導(dǎo)向，因此數(shù)據(jù)挖掘的工作量非常多。
數(shù)據(jù)挖掘主要是基于Hadoop集群。豌豆莢有一個(gè)數(shù)據(jù)挖掘團(tuán)隊(duì)專門做產(chǎn)品研發(fā)（主要是面向內(nèi)部），而豌豆莢這個(gè)團(tuán)隊(duì)則提供硬件資源和底層的Hive、HBase等基礎(chǔ)設(shè)施的支撐和維護(hù)。整體的數(shù)據(jù)量、計(jì)算量一直都在增長，一開始的幾年增長極快，最近幾年稍微慢一些，也有每年幾倍的增長。
差不多在2011年左右，豌豆莢開始嘗試做海外版的豌豆莢Snappea。當(dāng)時(shí)評估過在海外自建機(jī)房的可行性，在考察過各個(gè)地方不同位置、不同IDC、不同運(yùn)營商的選項(xiàng)之后，豌豆莢發(fā)現(xiàn)即使在進(jìn)展順利的情況下，也至少需要兩三個(gè)月才能建成，這個(gè)時(shí)間成本太高。如果不自建，那就只有公有云這一個(gè)選擇，正好當(dāng)時(shí)豌豆莢很多工程師都自己用過亞馬遜的AWS，出于時(shí)間、知識門檻、成本的考量，就決定在海外使用AWS作為豌豆莢的基礎(chǔ)支撐。
團(tuán)隊(duì)
EP團(tuán)隊(duì)的目標(biāo)很明確：在主要產(chǎn)品的完整生命周期內(nèi)，實(shí)現(xiàn)一流的效率、質(zhì)量和服務(wù)穩(wěn)定性；至于具體用什么技術(shù)或者方法，則并不做限制。一開始豌豆莢團(tuán)隊(duì)比較關(guān)注流程、開發(fā)工具等方面，現(xiàn)在豌豆莢對CI、代碼庫、自動化測試、運(yùn)維、基礎(chǔ)設(shè)施建設(shè)等各個(gè)方面都做了很多工作，有時(shí)候工程師要引入一些新的基礎(chǔ)設(shè)施相關(guān)的技術(shù)或框架，豌豆莢也會進(jìn)行review它們是不是靠譜，總的目標(biāo)就是讓產(chǎn)品從開始開發(fā)到線上生產(chǎn)環(huán)境運(yùn)行這整條路徑下，其穩(wěn)定性和質(zhì)量都有所保證。
現(xiàn)在整個(gè)團(tuán)隊(duì)的全職工程師有不到三十人，其中運(yùn)維團(tuán)隊(duì)有十個(gè)人，而且他們也都會承擔(dān)開發(fā)任務(wù)（豌豆莢叫做SRE，網(wǎng)站可靠性工程師），運(yùn)維過程中需要什么工具、支持系統(tǒng)，都是由他們自己開發(fā)。運(yùn)維團(tuán)隊(duì)的主要工作都在維護(hù)豌豆莢自建的機(jī)房系統(tǒng)上，AWS上面現(xiàn)在平均投入的維護(hù)人力差不多只有三分之一個(gè)人。這一方面是因?yàn)锳WS的維護(hù)成本確實(shí)低，另一方面也是因?yàn)橥愣骨v在AWS上面的規(guī)模還不是太大。
從代碼庫到生產(chǎn)環(huán)境
豌豆莢的產(chǎn)品發(fā)布流程還是相對成形的。不同的產(chǎn)品線有不同的發(fā)布頻率，比較穩(wěn)定的在一周兩次，有些比較早期的項(xiàng)目可能一天一次，沒有太大的壓力。
產(chǎn)品下一個(gè)release要發(fā)布哪些feature、發(fā)布周期設(shè)置成多久間隔，主要是由產(chǎn)品經(jīng)理和設(shè)計(jì)師來決定，工程師實(shí)現(xiàn)需求。到了發(fā)布日期截止之前，從代碼庫的主干拉一支發(fā)布分支出來做feature freeze和最后的驗(yàn)收測試，到發(fā)布分支上只能做bug修復(fù)，不再接受新的feature。
有的產(chǎn)品線有統(tǒng)一的測試機(jī)制，有的產(chǎn)品線則主要靠工程師自己做測試。無論是哪種測試模式，在進(jìn)入CI做集成之前和之后都會統(tǒng)一進(jìn)行靜態(tài)檢查和已有的單元測試用例，然后才上到staging環(huán)境。從staging環(huán)境開始就屬于運(yùn)維負(fù)責(zé)的領(lǐng)域了，豌豆莢的staging沒有真實(shí)的流量，但是環(huán)境跟線上是一模一樣的，可以說是一直處在最新版本的服務(wù)，然后staging再跟線上環(huán)境同步代碼。
這一套自動發(fā)布、部署的流程雖然也不是很完善，比如持續(xù)集成的檢查點(diǎn)還不夠多，單元測試率還比較低，不過還算跑的不錯(cuò)。現(xiàn)在AWS上也是同樣的一套部署過程，當(dāng)時(shí)適配起來也很快，大概做了一個(gè)星期就跑上去了。
監(jiān)控
豌豆莢的監(jiān)控系統(tǒng)要實(shí)現(xiàn)的目的無非是兩個(gè)：實(shí)時(shí)的報(bào)警，以及可以追溯的歷史數(shù)據(jù)，其他都是衍生的功能。跟大部分互聯(lián)網(wǎng)公司一樣，豌豆莢一開始做監(jiān)控也都是用開源軟件搭起來的，不過開源的監(jiān)控軟件現(xiàn)在越來越不能滿足豌豆莢的需求。
這里面有兩個(gè)挑戰(zhàn)：
性能問題
數(shù)據(jù)采集的定制化問題
數(shù)據(jù)采集的定制化主要是涉及到一些業(yè)務(wù)數(shù)據(jù)的采集，通用的開源軟件也還是要做適配，需要自己去寫實(shí)現(xiàn)，這個(gè)其實(shí)還好。性能問題是一個(gè)更加嚴(yán)重的問題，這個(gè)問題來自于三個(gè)方面：越來越多的機(jī)器、越來越多的采集項(xiàng)、越來越高的采集頻率。
以前豌豆莢監(jiān)控，可能5分鐘抓一次數(shù)據(jù)就行；現(xiàn)在豌豆莢希望做到秒級的采集。監(jiān)控系統(tǒng)需要有實(shí)時(shí)分析日志的能力，而到機(jī)器數(shù)量增長到千臺以上之后，要做秒級的采集和分析，無論是數(shù)據(jù)收集的速度還是數(shù)據(jù)分析的速度都會遇到瓶頸。
所以現(xiàn)在豌豆莢正在自己重寫一套監(jiān)控的系統(tǒng)，專門針對豌豆莢自建的機(jī)房體系，包括對多機(jī)房架構(gòu)的支持、與資產(chǎn)系統(tǒng)的對接等等。而AWS上豌豆莢直接使用了其CloudWatch監(jiān)控功能，目前來講完全夠用了。
新的挑戰(zhàn)
因?yàn)闃I(yè)務(wù)跟數(shù)據(jù)密切相關(guān)，而豌豆莢部門承擔(dān)了給數(shù)據(jù)分析團(tuán)隊(duì)提供基礎(chǔ)設(shè)施的責(zé)任。
業(yè)務(wù)對數(shù)據(jù)報(bào)告的需求一般有兩類：
1、定制化的、定期的數(shù)據(jù)指標(biāo)報(bào)告
此類報(bào)告有按天的、按周的、按月的或者按小時(shí)的，一般都是比較常規(guī)的監(jiān)測指標(biāo)，持續(xù)監(jiān)控、持續(xù)分析，中間數(shù)據(jù)保留完整，需要的計(jì)算量和存儲量容易預(yù)測。這種報(bào)告需求比較容易滿足。
2、按需出報(bào)告
此類需求經(jīng)常是針對之前沒有中間數(shù)據(jù)的監(jiān)測值，之前并不知道需要針對此類數(shù)值做分析，現(xiàn)在忽然發(fā)現(xiàn)需要了，業(yè)務(wù)部門會要求一次性分析過去半年到一年跟該數(shù)據(jù)相關(guān)的趨勢。此類報(bào)告往往很耗時(shí)，有時(shí)候豌豆莢做估算，一年的數(shù)據(jù)分析完畢需要用多長時(shí)間，結(jié)果可能是用豌豆莢現(xiàn)在的計(jì)算資源，可能要分析一個(gè)月才能產(chǎn)出他想要的報(bào)告，但這是無法滿足業(yè)務(wù)需求的。
要提高分析速度，最直接的做法就是投入更多的計(jì)算資源——放在豌豆莢自建的機(jī)房就是擴(kuò)容，如果用公有云就是起更多的實(shí)例。一方面擴(kuò)容是要做的，另一方面現(xiàn)在AWS進(jìn)入國內(nèi)，豌豆莢也在考察使用AWS來做這種任務(wù)的可能性。
實(shí)際上豌豆莢用了AWS以來，也逐漸發(fā)現(xiàn)豌豆莢之前系統(tǒng)設(shè)計(jì)的并不是那么好。比如豌豆莢在海外的數(shù)據(jù)分析，原本是想用EMR的，但是發(fā)現(xiàn)豌豆莢現(xiàn)在這套東西搬過去不好直接用，只好基于EC2來做這個(gè)事情。為什么呢？因?yàn)锳WS的理念是讓不同的組件做不同的事，比如EC2只做計(jì)算，數(shù)據(jù)持久化存儲最好都放在S3；但是豌豆莢的系統(tǒng)一開始設(shè)計(jì)并沒有考慮這些，數(shù)據(jù)都存在本地計(jì)算節(jié)點(diǎn)上，如果要重構(gòu)，需要投入的時(shí)間還是挺多的。
包括scaling這件事也是，現(xiàn)在豌豆莢基本沒有用到scaling，因?yàn)橥愣骨v的應(yīng)用上下游之間的依賴關(guān)系太重，所以對scaling機(jī)制支持的不好。這些都是需要努力的方向。一個(gè)比較好的事情是，豌豆莢豌豆莢的工程師都是比較有情懷的，對重構(gòu)這件事情比較支持。當(dāng)然，這里面有投入成本和產(chǎn)出的考量，豌豆莢首先要滿足的還是業(yè)務(wù)需求，解決業(yè)務(wù)問題，至于重構(gòu)的工作，會隨著豌豆莢在AWS上的業(yè)務(wù)規(guī)模更大而變得優(yōu)先級更高。
最后想分享的是，EC2的reserved instance如果用好了，能夠比on demand模式節(jié)省很多。豌豆莢一開始不知道AWS除了on demand之外還有reserved instance、spot instance這些玩法，最近才剛知道。Reserved instance非常適合Web Service使用，臨時(shí)性數(shù)據(jù)分析用spot instance則比較合適。
