淘寶發展歷程最具決定性的一次技術架構演變
今天我們重點說淘寶最重要的一次架構演變，這次演變在整個淘寶發展歷程中算是最具決定性的一次，沒有之一！
這套架構體系，如果你能用心掌握，足可以幫助你在任何一家網際網路大公司站穩腳跟！
淘寶技術發展歷史
前一篇文章“ 一位親歷者眼中的淘寶技術架構發展之路 ”，已經寫過淘寶技術架構 前兩個階段 的發展歷程。
今天我們重點說淘寶最重要的一次架構演變，也就是 第三到第四階段 。
淘寶第三階段面臨的挑戰
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映象等來支撐更大的流量，因此在真實的發展過程中還會有很多的不同，另外一個大型網站要做到的遠遠不僅僅上面這些，還有像安全、運維、運營、服務、儲存等等。
今天就寫到這了，如果你還有更多想了解的內容，還請關注優知學院。也可以訪問優知學院官網，免費報名參加線下的活動了解更多內容。