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

　　注：文中所有的技術點都可以在http://blog.csdn.net/cenwenchu79 找到詳細的文章，同時本文主要介紹開放平臺技術發展歷程，產品和業務內容不涵蓋在此，因此受眾群體主要是技術人員。

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

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

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

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

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

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

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