尊重原著,著明:本帖為優秀的文章整合
摘自《淘寶技術這10年》
1. 淘寶技術這10年
1.1. 淘寶現狀
高並發已經成為當前互連網企業面臨的巨大挑戰。例如2015年“雙十一”全球狂歡節正式落下帷幕,天貓最終交易額也達到了創紀錄的912.17億元。參與交易國家和地區達到232個,雙十一支付寶最高峰每秒處理的交易筆數是8.59萬筆,線上人數峰值達到4500萬。
淘寶的核心技術(國內乃至國際的Top,這還是2011年的資料)
擁有全國最大的分布式Hadoop叢集(雲梯,2000左右節點,24000核CPU,48000GB記憶體,40PB儲存容量)
全國分布80+CDN節點,能夠自動找尋最近的節點提供服務,支援流量超過800Gbps
不遜於百度的搜尋引擎,對數十億商品進行搜尋,全球最大的電商平台
頂尖的負載平衡系統,頂尖的分布式系統,頂尖的互連網思想,功能多樣運行極其穩定
豐富的生態產業以及先進的資料採礦技術
……很多很多 1.2. 淘寶技術演變,摘自《淘寶技術這十年》
馬總在2003年4月7日秘密叫來阿里巴巴的十位員工,來到杭州一個隱秘的毛坯房,要求他們在一個月左右的時間內做出一個C2C網站。結果當然還是直接買的快,一個基於LAMP架構的網站,原名是PHPAuction,老美開發的一個拍賣網站。當然必須要做修改才能用。
2003年底,淘寶註冊使用者23萬,PV 31萬/day,半年成交額3371萬
很顯然MySQL無法撐得起如此大的訪問量,資料庫瓶頸出現了。幸好阿里的DBA隊伍足夠強大,他們使用Oracle替代了MySQL。Oracle那時就已經有了強大的並發性訪問設計——串連池,從串連池取串連的耗費比單獨建立串連少很多。但是PHP當時並沒有官方提供支援語言串連池特性,於是多隆前輩用Google(不會是Baidu)搜到了一個開源的SQL Relay,於是資料庫軟體方面的瓶頸暫時解決了。
隨之而來的是面臨硬體效能瓶頸,阿里買了EMC的SAN存放裝置,加上Oracle高效能RAC,硬體容量也暫時沒問題了。
因為SQL Relay的問題實在過於嚴重,2004年於是淘寶終於做出了跨時代的決策——使用Java重寫網站。
淘寶請了Sun的進階工程師來幫忙做Java架構。那麼他們是如何做到修改程式設計語言而不改變網站使用呢——模組化替換,今天寫好了A模組,另開一個新網域名稱,將串連指向該模組,同時別的模組不變,等到全部模組完成的時候,原網域名稱放棄。Sun公司堅持使用EJB作為控制層,加上使用iBatis作為持久層,一個可擴充且高效的Java EE應用誕生了。
送走Sun的大牛們之後,阿里的資料存放區又遇到了瓶頸,於是忍痛買了一台IBM小型機,也就有了IOE(IBM + Oracle + EMC)這樣的傳說
2004年底,淘寶註冊使用者400萬,PV 4000萬/day,全網成交額10個億。
2005年Spring誕生了,早聞Spring架構在Web應用不可或缺,而在淘寶網,Spring也達到了Rod Johnson設計它的目的——替代EJB。
2005年底,淘寶註冊使用者1390萬,PV 8931萬/day,商品數目1663萬個。
考慮到未來的發展,這樣的設施架構只是勉強可以應付現在的要求。於是,CDN技術派上用場了,一開始使用商用的ChinaCache,後來使用章文嵩博士搭建低耗能CDN網路,淘寶網的效能越來越好了。
2006年底,淘寶註冊使用者3000萬,PV 15000萬/day,商品數目5000萬,全網成交額169億元。
淘寶在2007年之前,使用NetApp的商用儲存系統,但是仍然不夠應付迅速增長的趨勢。同年Google公布了GFS的設計思想,參照它的思想,淘寶也開發了自己的檔案系統——TFS每個使用者在TFS上擁有1GB的圖片儲存空間,這些都得益於TFS叢集的檔案儲存體系統以及大量的圖片伺服器。淘寶使用即時產生縮率圖,全域負載平衡以及一級和二級緩衝來保證圖片的訪問最佳化與高效訪問。
淘寶的伺服器軟體使用Tengine,一個被最佳化過的nginx模組。
淘寶分離出了UIC(User Information Center),供所有模組調用。多隆前輩再次為其編寫出了TDBM,完全是基於記憶體的資料緩衝(參考了memcached)。再然後,淘寶將TBstore和TDBM合并,寫出了Tair,一個基於Key-Value的分布式快取資料系統。然後升級了自己的iSearch系統。
2007年底,淘寶註冊使用者5000萬,PV 25000萬/day,商品數目1個億,全網成交額433億元。
...
Dubbo是阿里巴巴內部的SOA服務化治理方案的核心架構,每天為2000+個服務提供3,000,000,000+次訪問量支援,並被廣泛應用於阿里巴巴集團的各成員網站。Dubbo自2011年開源後,已被許多非阿里系公司使用。(WSDL,UDDI和SOAP(http+xml)是SOA基礎的基礎組件。WSDL用來描述服務;UDDI用來註冊和尋找服務;而SOAP,作為傳輸層,用來在消費者和服務提供者之間傳送訊息。SOAP是Web服務的預設機制,其他的技術為可以服務實現其他類型的綁定。一個消費者可以在UDDI註冊表(registry)尋找服務 ,取得服務的WSDL描述,然後通過SOAP來調用服務)
2. 技術發展曆程總結 2.1. 單節點架構
2.2. 叢集架構
2.3. 叢集+分布式架構