一、淘寶技術發展歷史

前一篇文章「一位親歷者眼中的淘寶技術架構發展之路」，已經寫過淘寶技術架構前兩個階段的發展歷程。

今天我們重點說淘寶最重要的一次架構演變，也就是第三到第四階段。

二、淘寶第三階段面臨的挑戰

1.從人員的角度。

維護一個代名工程Denali的百萬級代碼怪獸(雖然物理部署是分離的)，從發布到上線，從人員的角度，百號人同時在一個工程上開發，一旦線上出問題，所有代碼都需要回滾，從人員的角度，也基本忍受到了極致。

2.從業務的角度

淘寶包含太多業務：用戶、商品、交易、支付…等等，代碼已經嚴重影響到業務的效率，每個業務有各自的需求，技術需要快速跟上業務的發展步伐。

3.從架構的角度

從數據庫端oracle數據庫集中式架構的瓶頸問題，連接池數量限制(oracle數據庫大約提供5000個連接)，數據庫的CPU已經到達了極限90%。數據庫端已經需要考慮垂直拆分了。

從應用橫向角度，需要走向一個大型的分布式時代了。

4.從公司的角度

基本處於硬件橫向擴展(服務器端按照層次物理部署)，隨著淘寶的訪問量越來越大，橫向部署擴展很快將到頭，從架構的前瞻性角度來講，這次架構調整晚做不如早做，否則越到後面越棘手，長痛不如短痛，是時候做出決斷了！

5.從借鑒的角度

以上任何一條，足可以推動整個技術架構往後延伸。這里也不得不提到一點，淘寶的整個技術架構的發展，離不開整個java體系開源的力量，以及當時技術更為先進的前輩。這些包含ebay、google等，淘寶當初從他們身上借鑒和學習到的特別多，從技術架構的角度。淘寶後面的tddl這就是直接從ebay的dal身上借鑒而來，以及tfs(從google的gfs參考而來)。類似的參考案例還有很多很多，今天我們重點還是繼續談這次架構演變。

問題了都暴露出來了，關鍵是怎樣去解決，用怎樣的思路開啟？

三、怎樣來解決如此棘手的問題

當你面臨以上嚴峻問題，這個階段需要痛下決心，是否需要把這些問題徹底解決？

如果你要徹底解決，你肯定需要付出巨大的代價。這次淘寶架構演變無疑是最具決定性的一次，也是周期最長，挑戰最大的一次。系統將按照職責和業務進行垂直拆分，努力去打造一個大型的分布式應用以及廉價的服務器集群時代。

1.首先工程代碼垂直拆分

把整個工程代碼denali按照業務為單元進行垂直拆分，還需要按照業務為單元進行單獨的物理部署。

淘寶就把denali按照業務為單位拆分成了類似這樣的系統：UM(UserManger)、SM(ShopManager)..等等幾十個工程代碼。

2.所有接口訪問垂直拆分。

按照業務為單位，把所有調用相關的接口以業務為單元進行拆分(早期可以把接口放在上面的工程里，通過服務暴露接口)，以後再考慮單獨部署。

比如，一個店鋪系統，需要訪問一個用戶的頭像的接口，用戶頭像的接口是獨立部署在用戶中心(UIC)這邊的集群服務器上的。隨著拆分的進行，淘寶的業務接口中心就變成了：UIC(用戶中心服務)、SIC(店鋪中心服務)等等以業務為單元部署的集群。

如果涉及到獨立部署，這里就涉及到接口底層通信機制。由於淘寶的訪問量特別大，從早期就意識到需要定制一個自己定制的通信框架，也就是如今的HSF：一個高性能、穩定的通信框架，並且支持多種不同的通信和遠程調用方式。走到這一步涉及的知識體系非常的多，要求對通信、遠程調用、消息機制等有深入的理解和掌握，要求的都是從理論、硬件級、操作系統級以及所採用的語言的做到都有清楚的理解。

3.淘寶的中間件開始形成自己的矩陣。

如果仔細查看，你會發現中間件基本都是在解決數據庫端的瓶頸為主，比如oracle的連接池限制、以及減少對數據庫的訪問，需要中間的分布式動態緩存來減少數據庫端的訪問，以及減少對數據庫的訪問，把大量的小文件(圖片等)存儲在廉價的硬件服務器上，以及到了後面為什麼淘寶要堅定的去IOE(IBM的小型機，Oracle的數據庫，EMC的存儲設備),其實基本都是基於數據庫

端的壓力。

當你走到了去IOE階段，一定是數據庫服務器端節點之間的通信已經成為瓶頸，以及各個節點對數據的訪問控制將受制於事務處理的一致性等問題，還有受限於磁盤的機械轉速與磁臂的尋道時間，以及受限於磁盤存儲性能提升緩慢等問題。隨著訪問量越來越大，這些瓶頸早晚會碰到，這就是阿里厲害的地方，這是一家強控制的企業。這些必須要自己控制，所以去掉IOE就變得很合理了，沒有什麼轟轟烈烈的壯舉了。一切都是為了贏取業務的需要。當然，這里面也有阿里雲的考慮，畢竟這些服務要全面開放出來。關於IOE這個話題，以後再詳細說。

大家比較了解的分布式緩存Tair、分布式文件存儲TFS、異步通信Notify、淘寶數據庫Tddl、淘寶Session框架等等就屬於淘寶中間件團隊(底層架構組)。

4.數據庫端按照業務為單位進行垂直和水平拆分

按照業務為單位進行垂直拆分數據庫，拆分完後就是：交易數據庫、用戶數據庫、商品數據庫、店鋪數據庫等。

這里還有涉及到的數據庫的選型，垂直拆分的時候，把除核心系統(交易等)之外的數據庫，選用免費的mysql為好，畢竟oracle太貴了，非核心系統用oralce完全沒有必要。

還有就是水平擴展，分庫分表，再結合讀寫分離一起。當然，分庫分表需要涉及到對應的SQL路由規則主庫備庫等，所以淘寶就設計了一套TDDL來解決這些問題，應用端只需配置對應的規則即可，對應用端的沒有任何侵入的設計。

5.需要整理業務和接口等依賴關係

將一個龐大的應用拆分需要耗費很長的時間，需要進行業務的整理和系統依賴關係等等，比如，常用的訪問接口單獨提供出來服務，調用這個接口方要考慮依賴關係。

6.淘寶商品搜尋引擎ISearch

畢竟海量的商品需要搜尋，需要強大的搜尋引擎。採用自己開發的ISearch搜尋引擎來取代在Oracle數據庫中進行搜尋，降低數據庫服務器的壓力。做法比較簡單，每天晚上全量將Oracle小型機的數據dump出來，Build成ISearch的索引，當時商品量也不大，一台普通配置的服務器，基本上可以將所有的索引都放進去，沒做切分，直接做了一個對等集群。

7.淘寶開始建立自己的獨立CDN基站等基礎設施

8.需要建立自己的運維體系

用於解決依賴管理、運行狀況管理、錯誤追蹤、調優、監控和報警等一個個龐大的分布式應用的情況。淘寶的這個系統叫淘寶的哈勃望遠鏡。

9.機房容災等

還要考慮如果線上出問題後，需要有備用機房工作，也就是我們常說的機房異地容災，保證哪怕斷水斷電，不能斷淘寶。

真實的演變過程中還會借助像提升硬件配置、網路環境、改造操作系統、CDN鏡像等來支撐更大的流量，因此在真實的發展過程中還會有很多的不同，另外一個大型網站要做到的遠遠不僅僅上面這些，還有像安全、運維、經營、服務、存儲等等。

SOA微服務淘寶架構系列學習專題一共有8篇，本篇為該系列的第2篇，每天會依序更新，送你BAT架構師原創出品的【java架構師學習80期專題資料合集】，公眾號回復【架構】，立即領取。