淘寶構建開(kāi)放平臺的技術(shù)歷程(2)

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

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

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

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

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

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

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