上周六參加了一場由淘寶的架構師，曾憲杰先生主講的淘寶網架構分享。然后馬上就出差了，一直沒來得及總結，今晚比較有空，把這次聽到的比較有啟發的觀點記錄一下

一、為什么stateless比較有利于實現水平伸縮

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

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

但是相對于有狀態，stateless是更好的，主要有3個原因：

1、負載均衡不需要做session綁定，也就可以用更簡單的算法，比如隨機、取模等，把請求分配到任意server上，因此相對于session綁定的做法，性能會比較好

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

3、如果某一臺server down掉了，后續的請求就沒法繼續往這臺server發了，影響可用性

二、為什么淘寶開發session框架

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

所以session還是要用的，但是如果session都放在app server里，stateless就不容易實現了，而且為了HA，還涉及到session遷移的問題，會比較復雜。所以淘寶自己搞了一個session框架出來

具體的實現就不清楚，不過知道了這個思路，也不是很困難。我猜應該類似于把session集中放在session server里，其他的app server都來共享就可以了。然后將session server做成集群，避免單點故障。同時session遷移的事情，也就轉化成了集群的遷移

三、關于TFS

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

這塊我沒有怎么研究過，當天曾先生也沒有深入講，不是很了解，就不多說了

四、淘寶子應用之間的集成，為什么不使用ESB

淘寶在11年左右開始拆分應用，走“服務化”方向之后，應用拆分了很多個獨立的子應用（大約有1000個左右）

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

這主要是因為ESB更擅長處理異構系統的集成，而淘寶這將近1000個應用，基本都是JAVA應用，所以ESB的這個優勢不明顯；另外，增加機器水平伸縮，是淘寶的殺手锏，如果采用ESB架構的話，那在水平伸縮的時候，就連ESB那層也要一起伸縮，比較麻煩

五、特性開關和優雅降級

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

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

六、分布式的好處

我原本認為，在滿足條件的情況下，分布式架構會提升性能（條件是CPU是性能的瓶頸，以及大的任務可以分割成可并行的多個子任務）

不過那天曾憲杰先生反對這個看法，他認為分布式只會把本地調用變成RPC，帶來額外的傳輸損耗，所以不但不會提升性能，反而在大多數場景下，會降低性能

我覺得不盡然，有時候分布式應該還是能提升性能的，對于那種CPU密集型的計算來說。比如NASA不是有一個項目，是利用很多個人PC，來計算小行星數量還是什么的。這個好像又叫啥網格計算。不過，我們做的大多都是企業應用，或者互聯網應用，因此基本上CPU不是瓶頸（瓶頸主要在IO）；由于業務邏輯的關系，也很難說就能拆分成可并行的子任務，所以場景不太滿足。因此對于曾先生的這個看法，我還是相當認可的

那么，既然分布式對于性能有減無增，為什么還要用分布式呢，總結了下面3個原因：

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

2、提升開發效率。淘寶把一個應用拆分成很多子應用以后，就可以實現“小團隊維護小應用”，做到了“專人專事”，效率比較高。此外，小應用顯而易見，也更容易維護

3、實現“差異化水平伸縮”。這個詞是我自己瞎造的。考慮這種場景，數據庫只能支持10個連接，但是需要20個系統才能支撐http并發。那么這時候應該部署幾套應用來組成集群呢？10個肯定不行，并發撐不住；但是20個也不行，因為每個應用都直接連數據庫，又超過了數據庫連接的上限

如果實現了分布式，那么就可以這樣：部署10個service server，來連接數據庫，對上層提供服務；部署20個app server，來響應http請求，不直接連接數據庫。挺巧妙的，架構上也挺有美感

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

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

另一方面，分布式架構也是有壞處的。比如部署和調試都變得復雜了，淘寶有專門的運維工具和開發工具，來減少這種痛苦。提到了一個google的Dapper，和淘寶自研的eagle eye。有需要的時候可以研究下

七、數據庫的水平伸縮

相對于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的方案，互為補充

八、關于虛擬化

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

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

2、應用和具體硬件隔離，便于維護

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

淘寶非常重視對硬件和應用狀況的監控，好像由于歷史遺留原因，監控的工具很多是針對單個進程的。所以目前常見的做法，是一臺虛擬機上只啟一個JVM（單進程），和過去的監控工具相兼容（這里沒有詳細說，剛好那會我也有點累了，聽得不是很仔細，不知道有沒有理解錯）

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

九、OSGi在淘寶內部的使用

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

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

但是，基于OSGi框架做開發，復雜度的上升又是顯而易見的。因此，用很高的代價，只能換來較少的收益，在開發人員之間推動很困難，漸漸地就不怎么用了

我們之前的一個產品，也是類似的情況。公司內部一個平臺，三年前的一個主要賣點就是OSGi架構，好處也就是OSGi官方宣傳的那一套，而現在最新的版本也在“去OSGi化”，有一種走了彎路的感覺

我個人覺得，除了明顯增加開發復雜度之外，OSGi還有一個問題，就是和java ee規范的兼容性，離完美還是相去甚遠。就連最簡單的一個問題，“OSGi框架與servlet框架嵌套”，現在雖然有方案，但是同樣相當復雜。我覺得對于OSGi，目前還是保持適度的關注就可以了

十、去IOE化，后續的趨勢

這一節本來不想寫，是關于淘寶去IOE化，以及后續的技術規劃。感覺沒有什么新東西，但是大領導就喜歡聽這些。還是先記一下，后面寫膠片說不定有用

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

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

十一、總結

本文大致記錄了那天的收獲，有些內容很受啟發；另外一些當前不太用得上，先記錄下來留著以后再想想

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

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

一整天的交流下來，我能感受到淘寶一種很務實的精神，我感覺這是我司目前所缺少的。曾先生多次提到“先work，再優化”、“當時也沒想那么多，只是先解決問題，不然就死了”、“專人專事，小團隊負責小系統”，我覺得很樸實，但是很有道理

反觀我司，現在動輒就100多號人做一個小產品，想用數量彌補質量的不足。實際上我覺得反而是降低了效率（這些產品我覺得10個人左右的小團隊，完全可以做得更好），同時也造就了大量的領導崗位，催生了各種流程，進一步降低了效率

還很喜歡搞“架構”，花了很多的資源，最終卻沒有在產品中落地，帶來什么業務價值，只是把產品做得更爛，同時制造了一些“專家”

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

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

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

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

總結

以上是生活随笔為你收集整理的淘宝网架构分享总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。