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

　　注：文中所有的技術(shù)點(diǎn)都可以在http://blog.csdn.net/cenwenchu79 找到詳細的文章，同時(shí)本文主要介紹開(kāi)放平臺技術(shù)發(fā)展歷程，產(chǎn)品和業(yè)務(wù)內容不涵蓋在此，因此受眾群體主要是技術(shù)人員。

　　2006年底，阿里巴巴提出了workat alibaba的戰略，20來(lái)號人就被拉到湖畔花園馬云的公寓里面開(kāi)始一個(gè)叫阿里軟件的公司創(chuàng )業(yè)。當時(shí)對于Work at alibaba有個(gè)朦朦朧朧的感覺(jué)，就是要為中小企業(yè)提供一個(gè)工作平臺，但是工作平臺又需要是一個(gè)開(kāi)放的平臺，因為賣(mài)家的需求是長(cháng)尾的，當時(shí)火熱的 salesforce給了阿里人一些啟示，那就是做一個(gè)支持二次開(kāi)發(fā)的工作平臺，半開(kāi)放式的來(lái)滿(mǎn)足各種賣(mài)家的長(cháng)尾管理需求。此時(shí)，軟件市場(chǎng)上就開(kāi)始培養起來(lái)最早的一批TP(淘寶開(kāi)放合作伙伴)，迄今為止很多非常成功的TP就是從那個(gè)時(shí)候開(kāi)始進(jìn)入淘寶賣(mài)家市場(chǎng)。

　　但經(jīng)過(guò)一年的平臺建設，發(fā)現開(kāi)發(fā)者非常難利用平臺做二次開(kāi)發(fā)，只有阿里軟件公司內部團隊構建了三個(gè)不同的CRM軟件。這時(shí)候淘寶來(lái)了一個(gè)業(yè)界的技術(shù)牛人：王文彬(花名：菲青)，這位淘寶新晉的首席架構師找到阿里軟件的平臺架構團隊，談到了當時(shí)業(yè)界還非常新穎的一種技術(shù)平臺：開(kāi)放平臺，由于阿里軟件已經(jīng)在做類(lèi)似的開(kāi)放工作，希望能夠合作的方式來(lái)試水開(kāi)放平臺。當時(shí)雙方都是一種嘗試的態(tài)度，因此最后敲定，投入一個(gè)人，兩周時(shí)間，看是否能夠出原型，如果可以，那么就繼續做，如果出不了原型，那么就此結束。兩周時(shí)間，負責阿里軟件的架構師放翁，參看著(zhù)美國雅虎的開(kāi)放模式，吭哧吭哧的就搞出了開(kāi)放平臺第一個(gè)雛形，沒(méi)想到就這樣開(kāi)啟了5年的開(kāi)放之路。后面會(huì )根據時(shí)間軸來(lái)說(shuō)一下開(kāi)放平臺的產(chǎn)品和技術(shù)的變革，每一年會(huì )發(fā)生很多事情，但是調出的一點(diǎn)一滴是當年最有感觸的。

　　07年：萌芽。SOA 盛行的年代，內部架構服務(wù)化成為開(kāi)放的第一步，內部服務(wù)不做好隔離，開(kāi)放就意味著(zhù)風(fēng)險不可控。支付寶今天的服務(wù)框架SOFA(類(lèi)ESB)，淘寶的 HSF(OSGI)，阿里軟件的ASF(SCA)都是那個(gè)年代的產(chǎn)物，但服務(wù)化帶來(lái)的痛卻是一樣的，不論是OSGI或者SCA之類(lèi)的服務(wù)框架，本身服務(wù)化規約設計都類(lèi)似，但難題也都擺在每個(gè)架構師和開(kāi)發(fā)者面前：服務(wù)單元Bundle的粒度控制，服務(wù)之間依賴(lài)管理，性能與規范的沖突，調試與隔離的平衡。這些都使得一線(xiàn)開(kāi)發(fā)者和平臺框架實(shí)現者出現非常多的矛盾，而這個(gè)過(guò)程最后能活下來(lái)的框架，最后都是摒棄掉了很多企業(yè)級的設計思路，因為SOA架構從企業(yè)級產(chǎn)品演變而來(lái)，而服務(wù)化后的內部平臺要面對的開(kāi)放平臺天生就是互聯(lián)網(wǎng)的產(chǎn)物。

　　08年：雛形。這一年到年底，平臺開(kāi)放淘寶服務(wù)30個(gè)，每天調用量2000w，這一年的開(kāi)放平臺的開(kāi)發(fā)者面向的客戶(hù)主要是阿里巴巴上的中小企業(yè)和淘寶C店賣(mài)家。開(kāi)放平臺建設初期要解決的就是三個(gè)問(wèn)題：1.服務(wù)路由。(外部可以獲取內部信息)2.服務(wù)接口標準化。(統一方式的獲得各種標準化信息)3.授權。(外部合法的獲取內部信息)。服務(wù)路由其實(shí)就是寫(xiě)一個(gè)高效的HttpAgent，服務(wù)接口標準化就是對象文本化(Json，xml)。今天在各大開(kāi)放平臺廣為使用的 OAuth協(xié)議，當前處于0.6版本，沒(méi)有任何實(shí)際的互聯(lián)網(wǎng)開(kāi)放平臺使用，直到Google 08年底慢慢對外推廣開(kāi)放的時(shí)候，OAuth被封裝到Google的Open SDK中，才使得很多中小互聯(lián)網(wǎng)公司使用這種看似及其復雜的兩階段授權交互模式。淘寶初期采用的是自有協(xié)議，因為OAuth2以前的邏輯復雜且使用不方便，直到2011年才開(kāi)始支持OAuth2，同時(shí)做了部分的安全增強。授權解決了開(kāi)放最大的一個(gè)問(wèn)題：用戶(hù)安全的對應用訪(fǎng)問(wèn)其數據受信。用戶(hù)從此不用赤裸裸的將用戶(hù)名密碼交給一個(gè)應用軟件，應用也可以在允許的范圍內(操作，數據，授權時(shí)長(cháng))充分利用用戶(hù)授權來(lái)玩轉創(chuàng )意。

　　有了上面的三板斧(路由，數據規范，授權)，開(kāi)放平臺正式開(kāi)門(mén)迎客了，沒(méi)有對外做任何的推廣，數據就蹭蹭蹭的走到了第一個(gè)1000w日均調用，此時(shí)兩個(gè)互聯(lián)網(wǎng)的新興技術(shù)開(kāi)始在開(kāi)放平臺中嘗試，Memcached和Hadoop。今天看來(lái)這兩個(gè)技術(shù)已經(jīng)被大規模使用，08年時(shí)卻是在吃螃蟹，2臺虛擬機要抗 1000w的路由，勢必要求對于路由和校驗信息能夠有足夠強的緩存，Memcached無(wú)疑是最好的選擇，但當時(shí)號稱(chēng)分布式緩存的Memcached其實(shí)是集中式緩存的一種，正真的分布式緩存都還在糾結于一致性和效率的問(wèn)題(2,3階段提交)。此時(shí)需要有一種方式能夠保證效率(可擴展)和穩定性，于是我們封裝了Memcached客戶(hù)端，提升當時(shí)BIO的Java客戶(hù)端的性能，同時(shí)引入了客戶(hù)端負載均衡和容災的設計，這種設計已經(jīng)被應用在現在很多大型分布式系統里面。另一方面每天上千萬(wàn)的訪(fǎng)問(wèn)也讓技術(shù)和產(chǎn)品對訪(fǎng)問(wèn)的行為有很強的分析需求，此時(shí)Hadoop在雅虎的充分利用引起了我們的重視(當時(shí)的雅虎技術(shù)創(chuàng )新一直都是業(yè)界的領(lǐng)頭人)，通過(guò)僅有的兩臺機器和一堆技術(shù)文檔，摸索著(zhù)我們搭建了公司內部的第一個(gè)Hadoop集群，而所寫(xiě)的hadoop入門(mén)實(shí)踐也成為當時(shí)Hadoop入門(mén)的基礎文檔，對于每天2000w的日志分析需求來(lái)說(shuō)，hadoop用的是游刃有余，但隨著(zhù)業(yè)務(wù)的不斷發(fā)展，hadoop離線(xiàn)分析所帶來(lái)的問(wèn)題也凸顯出來(lái)，MR程序面對靈活多變的分析需求顯得不易維護且效率低下(數據反復讀取分析)，于是我們也開(kāi)始思考怎么來(lái)改進(jìn)一下這個(gè)新玩意兒。

　　09年：產(chǎn)品化。這一年到年底，平臺開(kāi)放淘寶服務(wù)100多個(gè)，每天調用量4000w，這一年是開(kāi)放平臺的開(kāi)發(fā)者面對的主要是淘寶C店賣(mài)家，賣(mài)家工具成為服務(wù)市場(chǎng)的主流。這一年是變化的一年，阿里軟件年中的分拆使得開(kāi)放平臺的歸屬有些微妙，一種情況是留在阿里云，作為集團的基礎設施，另一種情況就是跟著(zhù)主要的業(yè)務(wù)需求方淘寶走，最后我們還是說(shuō)服了博士，結束了阿里軟件的老平臺，淘寶正式開(kāi)始自己的開(kāi)放之路。來(lái)到了淘寶，業(yè)務(wù)開(kāi)放迅猛增長(cháng)，從30個(gè)API猛增到了100個(gè) API，沒(méi)有對外做任何業(yè)務(wù)推廣，平臺調用量到了年底翻番。此時(shí)技術(shù)上的挑戰又聚焦到了性能上，一次API call的業(yè)務(wù)消耗平均在30-40ms，開(kāi)放平臺當時(shí)的平臺處理消耗平均在10ms左右。我們做了數據打點(diǎn)和分析，發(fā)現最大的消耗在于互聯(lián)網(wǎng)數據接收，同時(shí)大量的圖片數據上行，更是加大了平臺處理時(shí)間，同時(shí)從訪(fǎng)問(wèn)日志分析中可以看到很多無(wú)效的請求也占用了非常多的處理時(shí)間，這也意味著(zhù)無(wú)效請求和有效請求一樣在消耗著(zhù)有限的容器線(xiàn)程資源。于是我們開(kāi)始嘗試自己封裝字節流解析模塊，按需解析上行數據，一來(lái)提升數據分析的性能(并行業(yè)務(wù)和數據增量分析操作)，二來(lái)可以用最小代價(jià)處理異常請求(當發(fā)現不滿(mǎn)足業(yè)務(wù)規范，則立刻丟棄后續所有數據)，這塊實(shí)現被叫做LazyParser，主要的實(shí)現重點(diǎn)就是最小化數據緩存來(lái)并行業(yè)務(wù)和數據解析操作，上線(xiàn)后效果不錯，整體處理平均處理時(shí)間從10ms降低到了4ms。(包含了異常處理的優(yōu)化和解析性能的提升)

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