【轉發】淘寶網架構分享總結

發表時間：2013-07-04   最後修改：2013-07-04

上週六參加了一場由淘寶的架構師，曾憲傑先生主講的淘寶網架構分享。而後立刻就出差了，一直沒來得及總結，今晚比較有空，把此次聽到的比較有啓發的觀點記錄一下 

1、爲何stateless比較有利於實現水平伸縮 

關於什麼是stateless的掃盲，見這個貼：http://kyfxbl.iteye.com/blog/1831869 

通常有一個共識，就是把應用作成無狀態的，會比較容易實現水平伸縮。可是之前一直有一個想法，就算應用是有狀態的，也能夠作成水平伸縮：只須要在負載均衡那裏作一個session綁定就能夠了，根據某種標識，把請求固定地發送到特定的server上 

可是相對於有狀態，stateless是更好的，主要有3個緣由： 

一、負載均衡不須要作session綁定，也就能夠用更簡單的算法，好比隨機、取模等，把請求分配到任意server上，所以相對於session綁定的作法，性能會比較好 

二、也是性能的問題，在7層網絡模型中，session位於第7層，負載均衡若是是基於session的算法來決定要怎麼分發請求，性能的損耗也會比較大 

三、若是某一臺server down掉了，後續的請求就無法繼續往這臺server發了，影響可用性 

2、爲何淘寶開發session框架 

若是將請求所需的信息，都放在cookie裏，確實就不須要session框架了，並且也比較容易實現stateless。可是cookie也有本身的問題，cookie的大小是有限制的，還會增大網絡流量（對於淘寶這種規模的應用，絕對不是一個小數），而且數據放在客戶端，多少有點不安全 

因此session仍是要用的，可是若是session都放在app server裏，stateless就不容易實現了，並且爲了HA，還涉及到session遷移的問題，會比較複雜。因此淘寶本身搞了一個session框架出來 

具體的實現就不清楚，不過知道了這個思路，也不是很困難。我猜應該相似於把session集中放在session server裏，其餘的app server都來共享就能夠了。而後將session server作成集羣，避免單點故障。同時session遷移的事情，也就轉化成了集羣的遷移 

3、關於TFS 

在《淘寶技術這10年》這本書裏，「淘寶大學」的校長神話了這個技術。那天據曾憲傑先生說，TFS只是比較擅長處理小而多的零散文件，單機部署時性能也不是很好，可是在集羣部署時，性能和可用性，確實有一點優點 

這塊我沒有怎麼研究過，當天曾先生也沒有深刻講，不是很瞭解，就很少說了 

4、淘寶子應用之間的集成，爲何不使用ESB 

淘寶在11年左右開始拆分應用，走「服務化」方向以後，應用拆分了不少個獨立的子應用（大約有1000個左右） 

這麼多的應用要在一塊兒完成業務，勢必涉及到集成的問題。可是淘寶沒有使用ESB，而是用了自研的服務框架和消息中間件 

這主要是由於ESB更擅長處理異構系統的集成，而淘寶這將近1000個應用，基本都是JAVA應用，因此ESB的這個優點不明顯；另外，增長機器水平伸縮，是淘寶的殺手鐗，若是採用ESB架構的話，那在水平伸縮的時候，就連ESB那層也要一塊兒伸縮，比較麻煩 

5、特性開關和優雅降級 

稍微提到了一點，即在應用中放一些開關，在流量告警的時候，關閉一些功能，以主動避讓的方式，避免系統壓力過大而不可用。我理解相似於丟卒保車，在萬不得已的時候，犧牲一些次要的業務，保護主要的業務 

具體的實現沒有提到，目前好像咱們也沒碰到過這種場景，先簡單記錄一下 

6、分佈式的好處 

我本來認爲，在知足條件的狀況下，分佈式架構會提高性能（條件是CPU是性能的瓶頸，以及大的任務能夠分割成可並行的多個子任務） 

不過那天曾憲傑先生反對這個見解，他認爲分佈式只會把本地調用變成RPC，帶來額外的傳輸損耗，因此不但不會提高性能，反而在大多數場景下，會下降性能 

我以爲不盡然，有時候分佈式應該仍是能提高性能的，對於那種CPU密集型的計算來講。好比NASA不是有一個項目，是利用不少我的PC，來計算小行星數量仍是什麼的。這個好像又叫啥網格計算。不過，咱們作的大多都是企業應用，或者互聯網應用，所以基本上CPU不是瓶頸（瓶頸主要在IO）；因爲業務邏輯的關係，也很難說就能拆分紅可並行的子任務，因此場景不太知足。所以對於曾先生的這個見解，我仍是至關承認的 

那麼，既然分佈式對於性能有減無增，爲何還要用分佈式呢，總結了下面3個緣由： 

一、組件複用。這個很好理解，就不用多說了 

二、提高開發效率。淘寶把一個應用拆分紅不少子應用之後，就能夠實現「小團隊維護小應用」，作到了「專人專事」，效率比較高。此外，小應用顯而易見，也更容易維護 

三、實現「差別化水平伸縮」。這個詞是我本身瞎造的。考慮這種場景，數據庫只能支持10個鏈接，可是須要20個系統才能支撐http併發。那麼這時候應該部署幾套應用來組成集羣呢？10個確定不行，併發撐不住；可是20個也不行，由於每一個應用都直接連數據庫，又超過了數據庫鏈接的上限 

若是實現了分佈式，那麼就能夠這樣：部署10個service server，來鏈接數據庫，對上層提供服務；部署20個app server，來響應http請求，不直接鏈接數據庫。挺巧妙的，架構上也挺有美感 

固然，數據庫的鏈接數上限確定不僅是10個，上面只是打個比方。從側面也看出，淘寶的業務量大到了一個超乎我想象的程度——竟然連數據庫的鏈接都不夠用了 

同時，這麼多子系統要調來調去，是很複雜的（1000個子系統，想一想都以爲很複雜）。因此淘寶開發了服務框架和消息中間件，來解決這個問題。或者說，正是先行一步有了這些基礎框架，服務化拆分的路才能走得比較順暢 

另外一方面，分佈式架構也是有壞處的。好比部署和調試都變得複雜了，淘寶有專門的運維工具和開發工具，來減小這種痛苦。提到了一個google的Dapper，和淘寶自研的eagle eye。有須要的時候能夠研究下 

7、數據庫的水平伸縮 

相對於app的水平伸縮，數據庫伸縮是比較複雜的。由於RDBMS本質上是單機系統。雖然能夠部署N臺db server組成集羣，可是主要是保證了HA，也支撐更多的鏈接數。可是若是單個數據庫裏的數據量太大的話，讀寫都會變得很慢，仍是瓶頸 

最後沒有別的選擇，只能拆表，好比把user拆分紅user1和user2（拆分的維度能夠不少，基本上是水平拆分）。這就帶來2個問題，第一是編程變得複雜了，簡單的ORM+jdbc就搞不定了；第二就須要開始處理數據遷移的問題 

針對這2個問題，淘寶的答案是，用TDDL作數據庫路由，對上層應用保持透明；開發專門的遷移工具，在拆表後作數據遷移（儘量縮短業務中斷的時間） 

TDDL沒有開源，相似的有一個叫cobar的框架 

大致的思路應該是這樣的。原本應用的DAL層，直接就創建在JDBC之上，JDBC去連具體的數據庫 

 

可是這樣的話，應用就依賴底層的數據庫。當須要查詢一條數據的時候，應用須要知道應該去哪一個表（或者哪一個數據庫）裏查詢；在數據庫伸縮的時候，應用的代碼也要跟着改才行。這樣確定是不大好的 

因此，在DAL和JDBC之間，又增長了一層，也就是TDDL 

 

如今，DAL再也不是直接依賴JDBC，而是依賴TDDL。數據庫路由的功能，都在TDDL裏完成，底層數據庫伸縮的時候，也是在TDDL裏進行「配置」，應用的代碼不須要變化。果真是應了那句話，「計算機的問題，大多能夠經過增長一個抽象層來解決」 

TDDL的實現不清楚，也沒有開源。不過我猜想應該也是封裝成一個DataSource，適配JDBC規範，這樣其上的ORM框架，也就能夠直接使用了。而後在TDDL內部，會去解析SQL，處理配置文件（數據庫路由），而且依賴廠商JDBC的實現，去真正鏈接底層的數據庫 

總的來講，淘寶這個基於TDDL的方案，仍是在解決RDBMS水平伸縮的問題。應該也正在引進NOSQL的方案，互爲補充 

8、關於虛擬化 

淘寶內部也用到了虛擬機，也就是私有云。大體有幾個好處： 

一、硬件一虛多，提高硬件利用率，降成本 

二、應用和具體硬件隔離，便於維護 

三、硬件的內存太大時，JVM對內存的管理不是很好，不如把一臺硬件虛擬化成多個虛擬機 

淘寶很是重視對硬件和應用情況的監控，好像因爲歷史遺留緣由，監控的工具不少是針對單個進程的。因此目前常見的作法，是一臺虛擬機上只啓一個JVM（單進程），和過去的監控工具相兼容（這裏沒有詳細說，恰好那會我也有點累了，聽得不是很仔細，不知道有沒有理解錯） 

另外淘寶用的虛擬化工具是linux container，好像跟VMware那套解決方案也不太同樣，不是徹底的虛擬機，而是更輕量級的硬件資源的隔離，後面能夠再研究一下 

9、OSGi在淘寶內部的使用 

如今基本不怎麼用了，OSGi主要的價值，在實際中體現得不太明顯 

好比類隔離，用更簡單的自定義ClassLoader也能夠實現；單機多版本服務，用的場景也不多；熱部署也不是很實用 

可是，基於OSGi框架作開發，複雜度的上升又是顯而易見的。所以，用很高的代價，只能換來較少的收益，在開發人員之間推進很困難，漸漸地就不怎麼用了 

咱們以前的一個產品，也是相似的狀況。公司內部一個平臺，三年前的一個主要賣點就是OSGi架構，好處也就是OSGi官方宣傳的那一套，而如今最新的版本也在「去OSGi化」，有一種走了彎路的感受 

我我的以爲，除了明顯增長開發複雜度以外，OSGi還有一個問題，就是和java ee規範的兼容性，離完美仍是相去甚遠。就連最簡單的一個問題，「OSGi框架與servlet框架嵌套」，如今雖然有方案，可是一樣至關複雜。我以爲對於OSGi，目前仍是保持適度的關注就能夠了 

10、去IOE化，後續的趨勢 

這一節原本不想寫，是關於淘寶去IOE化，以及後續的技術規劃。感受沒有什麼新東西，可是大領導就喜歡聽這些。仍是先記一下，後面寫膠片說不定有用 

淘寶有一個動做是去IOE（IBM的小型機、Oracle數據庫、EMC高端存儲）。早期的淘寶，主要靠的是高端硬件，思路就是用錢解決問題。可是這樣作的成本很高，淘寶的業務規模又擴張得太快，因此要用更經濟的方案。用PC Server、MySQL數據庫等，經過大量廉價的硬件，水平伸縮組成集羣，來替代昂貴的硬件，思路就是用技術解決問題。跟google的思路一致 

淘寶V4.0的幾個技術趨勢：頁面組件化、私有云部署、多終端。沒有什麼新東西，實際上咱們2012年也在考慮這幾個規劃，那天聽到曾憲傑先生說淘寶也想作這麼幾件事，我以爲有點驚訝，怎麼這麼巧。實際上咱們產品目前的規模（併發和數據量），連淘寶的零頭都不到，所以也不是很急迫，應該是預研性質的 

11、總結 

本文大體記錄了那天的收穫，有些內容很受啓發；另一些當前不太用得上，先記錄下來留着之後再想一想 

總的來講，我對曾憲傑先生的水平很佩服，淘寶架構師確實是名不虛傳 

此外還有一些技術以外的感悟，主要有2點 

一成天的交流下來，我能感覺到淘寶一種很務實的精神，我感受這是我司目前所缺乏的。曾先生屢次提到「先work，再優化」、「當時也沒想那麼多，只是先解決問題，否則就死了」、「專人專事，小團隊負責小系統」，我以爲很樸實，可是頗有道理 

反觀我司，如今動輒就100多號人作一個小產品，想用數量彌補質量的不足。實際上我以爲反而是下降了效率（這些產品我以爲10我的左右的小團隊，徹底能夠作得更好），同時也造就了大量的領導崗位，催生了各類流程，進一步下降了效率 

還很喜歡搞「架構」，花了不少的資源，最終卻沒有在產品中落地，帶來什麼業務價值，只是把產品作得更爛，同時製造了一些「專家」 

我以爲淘寶也有這個趨勢。公司慢慢大了，優越感就來了，誇誇其談的風氣慢慢也滋生了。只能說，並非話多聲音大的就是專家，各人有各人的活法。我的感受，淘寶慢慢也會走向我司目前的狀態，可能這是大公司的通病，也是人的通病。。 

另一個感想，就是以爲淘寶如今有這麼一批技術高手，很大程度上是業務造就的。所謂時勢造英雄，業務規模不斷擴大，逼迫技術必須進步，解決業務問題，反過來也促進了業務的發展 

而做爲早期的淘寶技術人員，見招拆招，解決各類技術問題，慢慢也就成爲了高手。因此，應該要認可淘寶技術的強大，可是也要客觀看待，不必盲目神話和崇拜。淘寶作的也就是一個規模巨大的商城，不是原子彈或人類基因圖譜什麼的 

再次感謝曾憲傑先生，水平很棒，表達得也很好。下次有相似的機會，還會去參加