淘寶網架構分享總結
阿新 • • 發佈：2018-12-30
上週六參加了一場由淘寶的架構師，曾憲傑先生主講的淘寶網架構分享。然後馬上就出差了，一直沒來得及總結，今晚比較有空，把這次聽到的比較有啟發的觀點記錄一下
一、為什麼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個人左右的小團隊，完全可以做得更好），同時也造就了大量的領導崗位，催生了各種流程，進一步降低了效率
還很喜歡搞“架構”，花了很多的資源，最終卻沒有在產品中落地，帶來什麼業務價值，只是把產品做得更爛，同時製造了一些“專家”
我覺得淘寶也有這個趨勢。公司慢慢大了，優越感就來了，誇誇其談的風氣慢慢也滋生了。只能說，並不是話多聲音大的就是專家，各人有各人的活法。個人感覺，淘寶慢慢也會走向我司目前的狀態，可能這是大公司的通病，也是人的通病。。
另外一個感想，就是覺得淘寶現在有這麼一批技術高手，很大程度上是業務造就的。所謂時勢造英雄，業務規模不斷擴大，逼迫技術必須進步，解決業務問題，反過來也促進了業務的發展
而作為早期的淘寶技術人員，見招拆招，解決各種技術問題，慢慢也就成為了高手。所以，應該要承認淘寶技術的強大，但是也要客觀看待，沒必要盲目神話和崇拜。淘寶做的也就是一個規模巨大的商城，不是原子彈或人類基因圖譜什麼的
再次感謝曾憲傑先生，水平很棒，表達得也很好。下次有類似的機會，還會去參加