淘寶構建開放平臺的技術歷程(2)

　　另一方面，Hadoop的MR問題也日益突出，一大堆MR的class維護成本高，性能問題也隨之出現。此時我們開始嘗試抽象分析業務場景，想到的是是否能夠通過配置就可以完成各種統計分析需求。要用配置替代code，其實就看是否可以窮舉code所實現的各種統計需求。當回顧SQL的理念時，發現其實所有的統計在切割成為KV作為輸入輸出時，所涵蓋的需求無非是max,min,average,sum,count,distinct(這個是12年實現的，用了bloomfilter和AtomicLong)，再復雜一些無非就是上述幾個操作結果的數學表達式運算，因此KV輸入和KV輸出的離散統計配置需求已經抽象出來了，接著就是把統計完的一組組KV根據K來做Groupby，就生成了傳統意義上的報表。(K，v1,v2…)從此以后，每天的統計需求都通過配置來改變，再也沒有一大堆MR代碼，同時一次數據輸入就可以完成所有分析的處理，性能上得到了極大的提高。(后話，當后面有人推薦我們去看 hive，pig的時候，我們發現原來路都是這么走過來的)

　　雖然Hadoop每日分析抽象出模型配置解決了性能和易用性的問題，但是對于即時分析卻不太適合，當時出于監控的需求，希望能夠一個小時就可以對數據做一次增量的分析，用于監控服務整體的調用情況，保證對異常問題的即時排查。由于一天4000w的量還不算很大，因此當時就直接考慮采用Mysql分庫分表的方式然后定時的去做SQL的查詢，結果發現效果不錯。當然這個過程又產生了一個小組件，要直到4000w的日志數據寫磁盤和DB雙份必然會帶來不少的IO 消耗，同時這個系統并不是帳務系統，丟掉一點日志也沒關系，因此就采取了異步批量數據外寫的設計(多線程守護各自的一塊Buffer頁，定時外刷或者滿頁外刷)，這樣在雙寫的情況下，單機的Load也沒有超過0.7。

　　但快到年底的時候，發生了一件事情讓我們頭痛不已，同時也成為了開放平臺的一個“隱形炸彈”。一天晚上，突然發生平臺大規模拒絕服務的告警，半夜爬起來觀察了一下整個集群，發現業務處理時間從平均的30-40ms，上升到了1s，仔細觀察了一下，某一個業務的響應時間大幅攀升，從原來20ms的響應時間飆升到了1s以上，此時由于Http請求的同步性，導致前端服務路由網關的集群線程都釋放的非常慢，阻塞處理這個業務的請求，而其他正常的業務(淘寶開放平臺背后的服務是不同團隊維護，處理時間從1ms到200ms都有)也無法被訪問，因此才有了開始的全線告警的產生。當晚后面發現是這個業務團隊的一次發布中忽略了數據庫索引建立導致服務耗時增加，但這個問題開始時不時的來拜訪開放平臺，開放平臺穩定性受制于任何一個業務方，這是不可接受的～～～對于這個問題，起先考慮集群拆分，將重要業務和不重要業務拆分，考慮到實施成本(不同服務的利用率差異很大)和業務隔離是否徹底(重點業務也會相互影響)放棄了這個想法。當時又想到了軟負載切割，Haproxy和LVS，一個是七層的網絡軟負載切割，一個是四層的負載切割，由于涉及到業務，于是還是考慮走七層的軟負載切割，嘗試一臺Haproxy掛7臺虛擬機，然后運行期可動態調整配置在出現問題的時候可人工干預切割流量。就這樣，我們有了告警以后可以手動切割的半人工方式干預措施，起碼不在心驚肉跳時手足無措了。但我們依然晚上睡不踏實… (期間考慮過Web請求異步化，Servlet3的模式來規避同步Http帶來的平臺阻塞，但當時唯一支持Servlet3的jetty和 tomcat做壓力測試，效果都很不穩定)

　　10年：平臺化。這一年到年底，平臺開放淘寶服務300多個，每天調用量8億，這一年淘寶正式開始對外宣傳開放，淘寶開放年，贏在淘寶，很多今天年收上千萬的TP在這個時候成為了先鋒(10年以前的可以叫做先烈)，產品層面上，這一年除了賣家工具的繼續發展，SNS熱潮的興起帶動了淘江湖的買家應用，游戲應用的淘金者蜂蛹而入，開放的服務也繼續保持300%的增速，覆蓋面從賣家類延伸到了買家類，從簡單的API提供，到了淘寶網站支持深度集成應用到店鋪和社區。

　　8個億的訪問量下再用Mysql做流式分析已經不靠譜了，分析時間要求也從一個小時提升到了20分鐘，此時經過快1年半的Hadoop使用和學習，再加上對分布式系統的了解，正式開始寫第一版的流式分析系統，MR的抽象依舊保留，而底層的數據計算分析改用其他方式，這個“其他方式”和Hadoop的差異在于：1.分析任務數據來源于遠端服務器日志。(主要通過pull而非push)。2.任務分配和調度采用被動分配(有點類似于volunteer computing的模式)，mater 輕量的管理任務，slave加入即可要求執行任務，對任務執行的情況不監控，只簡單通過超時來重置任務狀態。3.任務統一由Master來做最后的 Reduce，Slave可以支持做Shuffle來減少數據傳輸量和Master的合并壓力，Master負責統一輸出結果到本地?？偟膩碚f就是數據來源變了，數據不通過磁盤文件來做節點計算交互(只在內存使用一次就丟掉了)，簡化任務調度，簡化數據歸并。這樣第一版本的流式分析出來了，當然后面這些設計遇到的挑戰讓這個項目不斷在演進，演進的各種優化幾年后發現都在hadoop或者Hive之類的設計中有類似的做法。(參看一下文章最頂部的blog地址根據時間軸可以看到各種結構優化和性能優化的過程)這個系統3臺虛擬機抗住了8億的日志即時分析，Mysql日志分析就此結束。

　　這一年另一個重大改變就是更多人對開放的價值有所認同，淘寶從一個部門的開放走到了淘寶公司的開放，什么叫做部門開放?就是在10年以前大部分的API開放都是開放平臺這個團隊來做封裝維護，30個api還可以支撐，100個api已經讓一個專業的小團隊應接不暇(當然不得不承認，迄今為止淘寶最有全局業務知識的還屬這個團隊的成員)，300多個api這種勢頭基本上就無法由一個團隊來作了，業務變更帶來的接口不穩定經常被投訴，因此我們啟動了服務輕量化的“長征項目”，逐漸通過工具和平臺將服務接入變成自動化的方式，將原來開放一個服務需要點對點，手把手花一周時間實施完成的過程，通過自動化服務發布平臺，一個人一天時間就可以發布一個服務，并且服務的文檔，多語言版本SDK都自動生成。這樣就具備了服務輕量化的基礎，然后將各個新開放的業務采用這種模式接入，而老業務逐漸的歸還給各個業務方去維護。這樣一來，服務的“穩定性”(業務方面)得到了非常大的提升，用戶對于服務的滿意度也得到了極大的提高。

原文轉自：http://www.kjueaiud.com