【51CTO.com原創稿件】沈詢，阿里巴巴中間件&穩定性平臺資深技術專家，在淘寶工作八年間，主要負責的產品有淘寶分布式數據庫（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 “云服務架構”專場的演講內容整理。

[[198954]]

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

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】

【責任編輯：wangxueyan TEL：（010）68476606】