阿里8年資深技術專家談企業級互聯網架構的演進之路

沈詢，阿里巴巴中間件&穩定性平臺資深技術專家，在淘寶工做八年間，主要負責的產品有淘寶分佈式數據庫（TDDL/DRDS）、分佈式消息系統(Notify/ONS)等，故對整個分佈式的互聯網架構比較瞭解。本文分享圍繞阿里技術架構演進及過程當中遇到的問題與企業級信息系統架構的演進展開。

阿里技術架構演進及過程當中遇到的問題

2003 年，淘寶最初的架構建設是採用 PHP，實踐發現系統抗壓能力相對薄弱。由於淘寶是一個企業級系統，因此選擇了當時很是重要的企業級技術 JavaBean。以後把整個 Web 的容器、EJB 等整套體系引入淘寶，僱用有經驗的工程師一塊兒作架構。淘寶在技術方面也走過很長的路，在架構建設過程當中，你們討論最多的事情是如何劃分模塊。

隨着技術的不斷髮展，到 2006 年，淘寶技術又從 EJB 過渡到 Spring，以下圖：

目前，這個產品已經開源，最上層採用的是 JBoss、中間採用 Webx，以後是 Spring、OR-Mapping，底層用到是 Oracle 數據庫。用 Search 作搜索引擎，是由於當時收購雅虎，把雅虎的搜索引擎掛接到淘寶。像這樣採用分佈式的存儲方式在如今看來很常見。

當時，業務不斷高速發展，一些問題隨之逐漸暴露出來。這裏主要分享工程維護、人員變更、數據孤島、數據集能力不足等問題。

工程維護與人員變更

隨着業務不斷壯大，技術團隊的工程也會愈來愈多，源代碼加速膨脹。多個工程之間，源代碼衝突嚴重同時由於工做沒有邊界致使相互協同的成本不可估量。

假設出現項目完成，核心人員離職的狀況，項目維護也會成爲問題，當新人入職以後，學習老代碼的難度也可想而知。

數據孤島

數據孤島是各個公司很廣泛的問題，在那個時期，天貓還叫淘寶商城，不是基於淘寶，而是徹底獨立的一個組。

後期由於一些緣由，想要把兩個體系合併，卻由於各自獨立的業務體系、用戶 ID、數據存儲格式等等差別致使操做困難。且數據自己質量不高，作統一分析也有難度。

數據庫能力達到上限

當時用的是小型機+Oracle，CPU90% 以上，每一年宕機最少一次。這主要是由於有大量新業務寫入，兩週一次的頻度，不斷地有新 SQL 產出。

在新的 SQL 中，如出現一個慢 SQL，就會出現宕機。當時咱們用的小型機重啓一次須要 20 分鐘，切換到異地也是 20 分鐘。

關於鏈接數問題，以下圖：

當時後端 Oracle 的鏈接池有限，約 8000 個左右，一旦超過就會出現問題。由於超過數量，連接佔的內存會很是大，且鏈接數單點風險系統很高。

阿里面對 DBA 相關問題的應對方法

綜上所述，當時阿里 DBA 面臨維護人員不少，團隊職責不清、數據沒法共享，團隊各自爲戰、小型機數據庫壓力過大，鏈接數單點風險系統很高等問題。

好在阿里那時正處於增加期，因此這時經過招聘一些技術大牛來解決問題。

基於 EDAS 進行服務化改造

針對阿里 DBA 遇到的問題，從硅谷請來的技術人用服務化的方式試着解決。當時在中國只有用友作過服務化，且效果不是很好，沒有借鑑，只能謹慎當心的本身往前走。

以下圖，是阿里以服務化方式將系統專業分工的三個關鍵戰役。

用戶中心服務化

選擇用戶中心的第一個是作服務化，由於用戶中心是最小集合，最簡單清楚，還由於確實有業務需求，也是想要驗證這條服務化的理念是否是正確。

服務化以前的用戶中心，有六個不同的查詢方法，看起來遍歷的方式差很少，但可能某個參數不一樣，由於數據來自不一樣的團隊。

服務化的原則是能不改不改，能簡化簡化，採用的傳輸方式是 HTTP。然而，這樣作行不通，是由於除了服務化 HTTP，其餘內容沒有改變，就須要佈設 Load Balance。

爲了保證 Load Balance 儘量穩定，因此選擇硬件 F5 來配置。把前端進入的用戶流量打到 F5，額外在增長新 VIP 接口，請求經過 F5 轉出去。

這裏發現一個很嚴重的問題，就是每當用戶登錄一次，出現一個節點，跳轉一次流量就要增長一倍。但 F5 是很貴的設備，將來若是全部都變成服務化，用 F5 就不可行。

千島湖項目

配置 F5 負載均衡行不通，換了另外一種思路就是由集中的單點模式變成真正意義的分散模式。當時阿里把這樣的方式叫軟負載，作的是分散負載均衡的事情。

當作交易中心服務化時，必然要用事物相關的方式，來保證整個流程的穩定性、一致性，當時採用的是最終一致性的設計方法。以後，經過實踐反覆修改，優化，獲得穩定的消息系統。

有了消息系統的研發經驗，隨後類目屬性等中心也隨之服務化，之因此叫千島湖項目，是由於你們很辛苦，完成項目以後去千島湖旅遊。

五彩石項目

隨着千島湖項目完成，底層架構、中間件的穩定，以後要作的事情就是把龐大的系統所有一次性服務化。

恰逢此時，淘寶商城和淘寶須要合併，因此整個系統在那個時期進行了完全的拆分，也就是淘寶 3.0。

以後再也沒有出現 4.0，一直採用服務化的架構方式。

基於 DRDS 進行數據庫分佈式改造

DRDS 建設初衷是但願對 Oracle 進行數據解析，同步到 MySQL 中。當時你們以爲 Oracle 很穩定，整個系統不會丟數據，因此要把 Oracle 放在主機。

但也發現一個問題，一是小型機比較貴重須要在後端加入大量 PC 機，進行讀寫分離。還有就是看似穩定的 Oracle，在 Linux 環境中表現不是很好，尤爲是二者還在兼容上存在不少問題。

以下，是傳統數據庫向分佈式數據庫的轉化圖：

最終選擇用分佈式的 MySQL 架構來解決問題，借鑑 Facebook 技術團隊開發的開源項目 Flashcache 機制，爲 MySQL 加速，完成整個業務的部署。在 Linux 環境下，MySQL 比 Oracle 更加穩定、運維成本也相對較低。

如上是作服務化中心帶來的好處，顯而易見。通過一段時間的改造以後，技術架構發生了很大變化，以下圖：

在整個技術架構的最底層是 EDAS、DRDS、ONS 等組成的基礎應用架構。電商、物流、移動IM、地理信息、醫療等都有本身的能力且都把能力進行開放，造成了IT共享業務架構層，用來支撐上層的業務。一旦業務須要合做，下層的技術能夠快速響應。

例如，淘寶和滴滴從談合做到項目順利完成，只用了不到五天的時間。當時是一個內網打車軟件，用這個軟件打車可實現經過公司帳戶去叫車，省去貼發票環節。

這件事情，真正的凸顯出，技術能夠幫助業務解決一些問題。雖然淘寶可能再也沒有 4.0 版本，但如今每套應用系統都是爲了將來而準備。

企業級信息系統架構的演進

經過對阿里技術發展歷程的總結，咱們發現這些通過實踐得出來的技術架構對一部分企業能夠起到借鑑的做用。因此規劃成一個產品——企業級信息系統。

雲計算時代，企業信息化演進不只僅是把 IT 系統搬到雲上，而是讓業務與信息系統深度融合，改變業務運營和創新模式。

以下圖，是企業級信息系統的演進過程：

把業務雲化，從虛擬機模式轉變成基於分佈式的互聯網架構進行重構，重構後給企業帶來的主要的價值是原來的一些效率問題得以解決。因此說，互聯網架構平臺是企業雲上演進的使能平臺。

以下圖是企業級互聯網架構平臺對應的下層架構：

最底層是基礎框架，主要涉及 EDAS、MQ 和 DRDS 三大產品：

• EDAS 主要職責是業務應用的編寫和發佈。

• MQ 是在異步解耦的過程當中，用來作消息的編輯和保證事物的一致性。

• 有大量的用戶和數據後，由 DRDS 負責分散到各個應用中去。

三個產品加起來，從上到下，很好地支撐業務的編寫、相互通訊以及下層數據的建設。

CSB（能力開放平臺）的主要職責是將阿里的 negligible 對外開放運營、保證內部數據的安全性和開放性，同時和現有的系統打通，進入到系統中去。雲化業務的能力部分，是和客戶一塊兒設計構建。整套系統到最後的核心關鍵點是成本、穩定和效率。阿里在業務高速增加的這十幾年實踐中，積累了不少這三方面的經驗。但願這些經驗能夠幫助一些企業少走彎路。

以下圖，是企業級互聯網架構的關鍵特徵：

隨着機器數量的增長，性能必定是線性增長、可靠性成指數型增加、運營成本要保持對數級上升。這些纔是真正互聯網架構的關鍵特徵，若是系統不能很好的解決這些問題，它會是一個沒法向上擴展的系統，那麼就沒法知足將來用戶的增加須要。

寫在最後

爲何會有這些互聯網系統？爲何會有這些互聯網架構的特徵？很簡單，由於阿里的軟件和服務最終是爲用戶服務的，當用戶成指數級增加時，系統沒有很好的擴展性，就必定會死。

什麼是企業級互聯網？就是若是光憑藉互聯網模式往前走，成本、研發效率等都會成爲問題。基於過往經驗，從新認知思考後，但願經過軟件的方式讓互聯網業務寫的更容易，更可以貼合企業高速增加的需求。

以上內容根據王晶昱老師在 WOTA2017 「雲服務架構」專場的演講內容整理。

2008 年加入淘寶後在中間件和穩定性平臺工做至今。目前負責阿里分佈式數據庫，以前叫 TDDL，如今運用到阿里雲上更名爲 DRDS、阿里的分佈式消息服務(Notify/MetaQ)，以及阿里企業級互聯網架構平臺的新產品研發工做。