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