豌豆莢作為創(chuàng)新工場的首批孵化項目之一，從2009年12月發(fā)展至今，用戶量已經(jīng)增長至4.1億。豌豆莢的主要業(yè)務(wù)在國內(nèi)，幫助用戶在手機上發(fā)現(xiàn)、獲取和消費應(yīng)用、游戲、視頻、電子書、壁紙等娛樂內(nèi)容，在東南亞地區(qū)等海外市場也做了類似的業(yè)務(wù)探索。

這樣一個快速增長的系統(tǒng)，對IT的底層支持也是一個相當(dāng)大的挑戰(zhàn)。本文將介紹豌豆莢在IT基礎(chǔ)架構(gòu)、工具、流程方面做過的一些事，在不同需求之間如何平衡，團隊職責(zé)的劃分，以及遇到的一些挑戰(zhàn)。

挑戰(zhàn)
豌豆莢創(chuàng)立初期國內(nèi)還沒有可靠的公有云服務(wù)，所以從2010年開始，豌豆莢通過自購服務(wù)器的方式，伴隨著豌豆莢在中國市場發(fā)展規(guī)模逐漸擴大，豌豆莢已經(jīng)在國內(nèi)建成了規(guī)模較大的數(shù)據(jù)中心。2014年豌豆莢開始國際化布局，但自建數(shù)據(jù)中心的方式卻很難在國外復(fù)制。“不同國家的采購流程和管理政策都不一樣，在一些東南亞國家，甚至基礎(chǔ)網(wǎng)絡(luò)提供商都千差萬別，自建機房不僅速度緩慢而且無法控制進度。”豌豆莢工程生產(chǎn)力部門質(zhì)量總監(jiān)高磊表示，“而業(yè)務(wù)部門又對迅速提供IT資源支持有著非常緊迫的要求，最終我們發(fā)現(xiàn)只用采用云服務(wù)才能真正解決我們的問題。”

為什么使用AWS
在決定采用云服務(wù)后，豌豆莢便確定了使用AWS，“我們的工程師團隊和運維人員對AWS比較熟悉，如果采用其他公有云產(chǎn)品勢必需要一個適應(yīng)和學(xué)習(xí)的過程，但我們使用AWS的學(xué)習(xí)成本很低，因此使用AWS可以說是順理成章。”質(zhì)量總監(jiān)高磊說。

除了減少團隊的學(xué)習(xí)成本，AWS服務(wù)與自身業(yè)務(wù)的高度契合也是促使豌豆莢決定采用AWS的重要原因。通過Amazon Elastic Compute Cloud (Amazon EC2)，豌豆莢提升了新產(chǎn)品在海外的發(fā)布速度，還可以根據(jù)實際使用量確定服務(wù)器計算資源，既提升了工作效率還顯著降低了成本，而且由于Amazon EC2的高可用性架構(gòu)，也大大提升了應(yīng)用的穩(wěn)定性和可用性。此外，豌豆莢還使用Amazon ElastiCache自動檢測并調(diào)換運行不暢的緩存節(jié)點，降低了基礎(chǔ)設(shè)備日常管理的費用，同時豌豆莢也使用Amazon ElasticCache集成的Amazon CloudWatch功能對設(shè)備進行監(jiān)控，從而更加準(zhǔn)確和清楚的了解與Redis等節(jié)點相關(guān)的性能指標(biāo)，保證服務(wù)和產(chǎn)品穩(wěn)定。

收益
如果豌豆莢采用傳統(tǒng)自建數(shù)據(jù)中心的形式，保守估計每個機房需要3-4個月才能完成，而在AWS上只需要幾分鐘便可以完成一切基礎(chǔ)設(shè)施的調(diào)試。更重要的一點，豌豆莢并沒有因為開始拓展海外業(yè)務(wù)增加任何運維人員，并且與負責(zé)傳統(tǒng)數(shù)據(jù)中心的人員投入相比，管理AWS日常運行所需要的人力幾乎可以忽略不計。在固定資本投入上，使用AWS與自建數(shù)據(jù)中心相比較，也能有一定程度的節(jié)約。不僅如此，通過對AWS收費政策的理解不斷加深，豌豆莢也發(fā)現(xiàn)了更多降低使用成本的方法。

豌豆莢與AWS的合作處于起步階段，隨著對AWS各項業(yè)務(wù)的了解不斷加深，豌豆莢還將繼續(xù)將更多業(yè)務(wù)遷移至AWS上。

基礎(chǔ)設(shè)施的建設(shè)與增長

豌豆莢誕生于2009年12月，機房部署是從2010年年初開始。那時候因為還沒有成熟的云服務(wù)可用，所以選擇了自建機房的方案。到目前為止，豌豆莢已經(jīng)在全國各地尤其是北京、天津地區(qū)建立了多個節(jié)點。

從對基礎(chǔ)設(shè)施資源使用的情況來看，豌豆莢的主要業(yè)務(wù)對帶寬和 CDN 資源用量會比較高；而從單一業(yè)務(wù)來看，各類數(shù)據(jù)挖掘和分析對服務(wù)器資源的占用是最大的。豌豆莢從創(chuàng)建一開始就是數(shù)據(jù)驅(qū)動的業(yè)務(wù)，有很強的用戶行為導(dǎo)向，因此數(shù)據(jù)挖掘的工作量非常多。

數(shù)據(jù)挖掘主要是基于Hadoop集群。豌豆莢有一個數(shù)據(jù)挖掘團隊專門做產(chǎn)品研發(fā)（主要是面向內(nèi)部），而豌豆莢這個團隊則提供硬件資源和底層的Hive、HBase等基礎(chǔ)設(shè)施的支撐和維護。整體的數(shù)據(jù)量、計算量一直都在增長，一開始的幾年增長極快，最近幾年稍微慢一些，也有每年幾倍的增長。

差不多在2011年左右，豌豆莢開始嘗試做海外版的豌豆莢Snappea。當(dāng)時評估過在海外自建機房的可行性，在考察過各個地方不同位置、不同IDC、不同運營商的選項之后，豌豆莢發(fā)現(xiàn)即使在進展順利的情況下，也至少需要兩三個月才能建成，這個時間成本太高。如果不自建，那就只有公有云這一個選擇，正好當(dāng)時豌豆莢很多工程師都自己用過亞馬遜的AWS，出于時間、知識門檻、成本的考量，就決定在海外使用AWS作為豌豆莢的基礎(chǔ)支撐。

團隊

EP團隊的目標(biāo)很明確：在主要產(chǎn)品的完整生命周期內(nèi)，實現(xiàn)一流的效率、質(zhì)量和服務(wù)穩(wěn)定性；至于具體用什么技術(shù)或者方法，則并不做限制。一開始豌豆莢團隊比較關(guān)注流程、開發(fā)工具等方面，現(xiàn)在豌豆莢對CI、代碼庫、自動化測試、運維、基礎(chǔ)設(shè)施建設(shè)等各個方面都做了很多工作，有時候工程師要引入一些新的基礎(chǔ)設(shè)施相關(guān)的技術(shù)或框架，豌豆莢也會進行review它們是不是靠譜，總的目標(biāo)就是讓產(chǎn)品從開始開發(fā)到線上生產(chǎn)環(huán)境運行這整條路徑下，其穩(wěn)定性和質(zhì)量都有所保證。

現(xiàn)在整個團隊的全職工程師有不到三十人，其中運維團隊有十個人，而且他們也都會承擔(dān)開發(fā)任務(wù)（豌豆莢叫做SRE，網(wǎng)站可靠性工程師），運維過程中需要什么工具、支持系統(tǒng)，都是由他們自己開發(fā)。運維團隊的主要工作都在維護豌豆莢自建的機房系統(tǒng)上，AWS上面現(xiàn)在平均投入的維護人力差不多只有三分之一個人。這一方面是因為AWS的維護成本確實低，另一方面也是因為豌豆莢在AWS上面的規(guī)模還不是太大。

從代碼庫到生產(chǎn)環(huán)境

豌豆莢的產(chǎn)品發(fā)布流程還是相對成形的。不同的產(chǎn)品線有不同的發(fā)布頻率，比較穩(wěn)定的在一周兩次，有些比較早期的項目可能一天一次，沒有太大的壓力。

產(chǎn)品下一個release要發(fā)布哪些feature、發(fā)布周期設(shè)置成多久間隔，主要是由產(chǎn)品經(jīng)理和設(shè)計師來決定，工程師實現(xiàn)需求。到了發(fā)布日期截止之前，從代碼庫的主干拉一支發(fā)布分支出來做feature freeze和最后的驗收測試，到發(fā)布分支上只能做bug修復(fù)，不再接受新的feature。

有的產(chǎn)品線有統(tǒng)一的測試機制，有的產(chǎn)品線則主要靠工程師自己做測試。無論是哪種測試模式，在進入CI做集成之前和之后都會統(tǒng)一進行靜態(tài)檢查和已有的單元測試用例，然后才上到staging環(huán)境。從staging環(huán)境開始就屬于運維負責(zé)的領(lǐng)域了，豌豆莢的staging沒有真實的流量，但是環(huán)境跟線上是一模一樣的，可以說是一直處在最新版本的服務(wù)，然后staging再跟線上環(huán)境同步代碼。

這一套自動發(fā)布、部署的流程雖然也不是很完善，比如持續(xù)集成的檢查點還不夠多，單元測試率還比較低，不過還算跑的不錯?，F(xiàn)在AWS上也是同樣的一套部署過程，當(dāng)時適配起來也很快，大概做了一個星期就跑上去了。

監(jiān)控

豌豆莢的監(jiān)控系統(tǒng)要實現(xiàn)的目的無非是兩個：實時的報警，以及可以追溯的歷史數(shù)據(jù)，其他都是衍生的功能。跟大部分互聯(lián)網(wǎng)公司一樣，豌豆莢一開始做監(jiān)控也都是用開源軟件搭起來的，不過開源的監(jiān)控軟件現(xiàn)在越來越不能滿足豌豆莢的需求。

這里面有兩個挑戰(zhàn)：

性能問題
數(shù)據(jù)采集的定制化問題
數(shù)據(jù)采集的定制化主要是涉及到一些業(yè)務(wù)數(shù)據(jù)的采集，通用的開源軟件也還是要做適配，需要自己去寫實現(xiàn)，這個其實還好。性能問題是一個更加嚴(yán)重的問題，這個問題來自于三個方面：越來越多的機器、越來越多的采集項、越來越高的采集頻率。

以前豌豆莢監(jiān)控，可能5分鐘抓一次數(shù)據(jù)就行；現(xiàn)在豌豆莢希望做到秒級的采集。監(jiān)控系統(tǒng)需要有實時分析日志的能力，而到機器數(shù)量增長到千臺以上之后，要做秒級的采集和分析，無論是數(shù)據(jù)收集的速度還是數(shù)據(jù)分析的速度都會遇到瓶頸。

所以現(xiàn)在豌豆莢正在自己重寫一套監(jiān)控的系統(tǒng)，專門針對豌豆莢自建的機房體系，包括對多機房架構(gòu)的支持、與資產(chǎn)系統(tǒng)的對接等等。而AWS上豌豆莢直接使用了其CloudWatch監(jiān)控功能，目前來講完全夠用了。

新的挑戰(zhàn)

因為業(yè)務(wù)跟數(shù)據(jù)密切相關(guān)，而豌豆莢部門承擔(dān)了給數(shù)據(jù)分析團隊提供基礎(chǔ)設(shè)施的責(zé)任。

業(yè)務(wù)對數(shù)據(jù)報告的需求一般有兩類：

1、定制化的、定期的數(shù)據(jù)指標(biāo)報告

此類報告有按天的、按周的、按月的或者按小時的，一般都是比較常規(guī)的監(jiān)測指標(biāo)，持續(xù)監(jiān)控、持續(xù)分析，中間數(shù)據(jù)保留完整，需要的計算量和存儲量容易預(yù)測。這種報告需求比較容易滿足。

2、按需出報告

此類需求經(jīng)常是針對之前沒有中間數(shù)據(jù)的監(jiān)測值，之前并不知道需要針對此類數(shù)值做分析，現(xiàn)在忽然發(fā)現(xiàn)需要了，業(yè)務(wù)部門會要求一次性分析過去半年到一年跟該數(shù)據(jù)相關(guān)的趨勢。此類報告往往很耗時，有時候豌豆莢做估算，一年的數(shù)據(jù)分析完畢需要用多長時間，結(jié)果可能是用豌豆莢現(xiàn)在的計算資源，可能要分析一個月才能產(chǎn)出他想要的報告，但這是無法滿足業(yè)務(wù)需求的。

要提高分析速度，最直接的做法就是投入更多的計算資源——放在豌豆莢自建的機房就是擴容，如果用公有云就是起更多的實例。一方面擴容是要做的，另一方面現(xiàn)在AWS進入國內(nèi)，豌豆莢也在考察使用AWS來做這種任務(wù)的可能性。

實際上豌豆莢用了AWS以來，也逐漸發(fā)現(xiàn)豌豆莢之前系統(tǒng)設(shè)計的并不是那么好。比如豌豆莢在海外的數(shù)據(jù)分析，原本是想用EMR的，但是發(fā)現(xiàn)豌豆莢現(xiàn)在這套東西搬過去不好直接用，只好基于EC2來做這個事情。為什么呢？因為AWS的理念是讓不同的組件做不同的事，比如EC2只做計算，數(shù)據(jù)持久化存儲最好都放在S3；但是豌豆莢的系統(tǒng)一開始設(shè)計并沒有考慮這些，數(shù)據(jù)都存在本地計算節(jié)點上，如果要重構(gòu)，需要投入的時間還是挺多的。

包括scaling這件事也是，現(xiàn)在豌豆莢基本沒有用到scaling，因為豌豆莢的應(yīng)用上下游之間的依賴關(guān)系太重，所以對scaling機制支持的不好。這些都是需要努力的方向。一個比較好的事情是，豌豆莢豌豆莢的工程師都是比較有情懷的，對重構(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ù)據(jù)分析用spot instance則比較合適。

香港快速服務(wù)器

版權(quán)聲明：本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習(xí)參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。