【51CTO.com原創(chuàng)稿件】沈詢，阿里巴巴中間件&穩(wěn)定性平臺資深技術(shù)專家，在淘寶工作八年間，主要負(fù)責(zé)的產(chǎn)品有淘寶分布式數(shù)據(jù)庫（TDDL/DRDS）、分布式消息系統(tǒng)(Notify/ONS)等，故對整個分布式的互聯(lián)網(wǎng)架構(gòu)比較了解。本文分享圍繞阿里技術(shù)架構(gòu)演進(jìn)及過程中遇到的問題與企業(yè)級信息系統(tǒng)架構(gòu)的演進(jìn)展開。

阿里技術(shù)架構(gòu)演進(jìn)及過程中遇到的問題

2003 年，淘寶最初的架構(gòu)建設(shè)是采用 PHP，實踐發(fā)現(xiàn)系統(tǒng)抗壓能力相對薄弱。因為淘寶是一個企業(yè)級系統(tǒng)，所以選擇了當(dāng)時非常重要的企業(yè)級技術(shù) JavaBean。之后把整個 Web 的容器、EJB 等整套體系引入淘寶，雇用有經(jīng)驗的工程師一起做架構(gòu)。淘寶在技術(shù)方面也走過很長的路，在架構(gòu)建設(shè)過程中，大家討論最多的事情是如何劃分模塊。

隨著技術(shù)的不斷發(fā)展，到 2006 年，淘寶技術(shù)又從 EJB 過渡到 Spring，如下圖：

目前，這個產(chǎn)品已經(jīng)開源，最上層采用的是 JBoss、中間采用 Webx，之后是 Spring、OR-Mapping，底層用到是 Oracle 數(shù)據(jù)庫。用 Search 做搜索引擎，是因為當(dāng)時收購雅虎，把雅虎的搜索引擎掛接到淘寶。像這樣采用分布式的存儲方式在現(xiàn)在看來很常見。

當(dāng)時，業(yè)務(wù)不斷高速發(fā)展，一些問題隨之逐漸暴露出來。這里主要分享工程維護(hù)、人員變動、數(shù)據(jù)孤島、數(shù)據(jù)集能力不足等問題。

工程維護(hù)與人員變動

隨著業(yè)務(wù)不斷壯大，技術(shù)團(tuán)隊的工程也會越來越多，源代碼加速膨脹。多個工程之間，源代碼沖突嚴(yán)重同時因為工作沒有邊界導(dǎo)致相互協(xié)同的成本不可估量。

假設(shè)出現(xiàn)項目完成，核心人員離職的情況，項目維護(hù)也會成為問題，當(dāng)新人入職之后，學(xué)習(xí)老代碼的難度也可想而知。

數(shù)據(jù)孤島

數(shù)據(jù)孤島是各個公司很普遍的問題，在那個時期，天貓還叫淘寶商城，不是基于淘寶，而是完全獨立的一個組。

后期因為一些原因，想要把兩個體系合并，卻因為各自獨立的業(yè)務(wù)體系、用戶 ID、數(shù)據(jù)存儲格式等等差異導(dǎo)致操作困難。且數(shù)據(jù)本身質(zhì)量不高，做統(tǒng)一分析也有難度。

數(shù)據(jù)庫能力達(dá)到上限

當(dāng)時用的是小型機(jī)+Oracle，CPU90% 以上，每年宕機(jī)最少一次。這主要是因為有大量新業(yè)務(wù)寫入，兩周一次的頻度，不斷地有新 SQL 產(chǎn)出。

在新的 SQL 中，如出現(xiàn)一個慢 SQL，就會出現(xiàn)宕機(jī)。當(dāng)時我們用的小型機(jī)重啟一次需要 20 分鐘，切換到異地也是 20 分鐘。

關(guān)于連接數(shù)問題，如下圖：

當(dāng)時后端 Oracle 的連接池有限，約 8000 個左右，一旦超過就會出現(xiàn)問題。因為超過數(shù)量，鏈接占的內(nèi)存會非常大，且連接數(shù)單點風(fēng)險系統(tǒng)很高。

阿里面對 DBA 相關(guān)問題的應(yīng)對方法

綜上所述，當(dāng)時阿里 DBA 面臨維護(hù)人員很多，團(tuán)隊職責(zé)不清、數(shù)據(jù)無法共享，團(tuán)隊各自為戰(zhàn)、小型機(jī)數(shù)據(jù)庫壓力過大，連接數(shù)單點風(fēng)險系統(tǒng)很高等問題。

好在阿里那時正處于增長期，所以這時通過招聘一些技術(shù)大牛來解決問題。

基于 EDAS 進(jìn)行服務(wù)化改造

針對阿里 DBA 遇到的問題，從硅谷請來的技術(shù)人用服務(wù)化的方式試著解決。當(dāng)時在中國只有用友做過服務(wù)化，且效果不是很好，沒有借鑒，只能謹(jǐn)慎小心的自己往前走。

如下圖，是阿里以服務(wù)化方式將系統(tǒng)專業(yè)分工的三個關(guān)鍵戰(zhàn)役。

用戶中心服務(wù)化

選擇用戶中心的第一個是做服務(wù)化，因為用戶中心是最小集合，最簡單清楚，還因為確實有業(yè)務(wù)需求，也是想要驗證這條服務(wù)化的理念是不是正確。

服務(wù)化之前的用戶中心，有六個不一樣的查詢方法，看起來遍歷的方式差不多，但可能某個參數(shù)不同，因為數(shù)據(jù)來自不同的團(tuán)隊。

服務(wù)化的原則是能不改不改，能簡化簡化，采用的傳輸方式是 HTTP。然而，這樣做行不通，是因為除了服務(wù)化 HTTP，其他內(nèi)容沒有改變，就需要布設(shè) Load Balance。

為了保證 Load Balance 盡可能穩(wěn)定，所以選擇硬件 F5 來配置。把前端進(jìn)入的用戶流量打到 F5，額外在增加新 VIP 接口，請求通過 F5 轉(zhuǎn)出去。

這里發(fā)現(xiàn)一個很嚴(yán)重的問題，就是每當(dāng)用戶登陸一次，出現(xiàn)一個節(jié)點，跳轉(zhuǎn)一次流量就要增加一倍。但 F5 是很貴的設(shè)備，未來如果所有都變成服務(wù)化，用 F5 就不可行。

千島湖項目

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

當(dāng)做交易中心服務(wù)化時，必然要用事物相關(guān)的方式，來保證整個流程的穩(wěn)定性、一致性，當(dāng)時采用的是最終一致性的設(shè)計方法。之后，通過實踐反復(fù)修改，優(yōu)化，得到穩(wěn)定的消息系統(tǒng)。

有了消息系統(tǒng)的研發(fā)經(jīng)驗，隨后類目屬性等中心也隨之服務(wù)化，之所以叫千島湖項目，是因為大家很辛苦，完成項目之后去千島湖旅游。

五彩石項目

隨著千島湖項目完成，底層架構(gòu)、中間件的穩(wěn)定，之后要做的事情就是把龐大的系統(tǒng)全部一次性服務(wù)化。

恰逢此時，淘寶商城和淘寶需要合并，所以整個系統(tǒng)在那個時期進(jìn)行了徹底的拆分，也就是淘寶 3.0。

之后再也沒有出現(xiàn) 4.0，一直采用服務(wù)化的架構(gòu)方式。

基于 DRDS 進(jìn)行數(shù)據(jù)庫分布式改造

DRDS 建設(shè)初衷是希望對 Oracle 進(jìn)行數(shù)據(jù)解析，同步到 MySQL 中。當(dāng)時大家覺得 Oracle 很穩(wěn)定，整個系統(tǒng)不會丟數(shù)據(jù)，所以要把 Oracle 放在主機(jī)。

但也發(fā)現(xiàn)一個問題，一是小型機(jī)比較貴重需要在后端加入大量 PC 機(jī)，進(jìn)行讀寫分離。還有就是看似穩(wěn)定的 Oracle，在 Linux 環(huán)境中表現(xiàn)不是很好，尤其是兩者還在兼容上存在很多問題。

如下，是傳統(tǒng)數(shù)據(jù)庫向分布式數(shù)據(jù)庫的轉(zhuǎn)化圖：

最終選擇用分布式的 MySQL 架構(gòu)來解決問題，借鑒 Facebook 技術(shù)團(tuán)隊開發(fā)的開源項目 Flashcache 機(jī)制，為 MySQL 加速，完成整個業(yè)務(wù)的部署。在 Linux 環(huán)境下，MySQL 比 Oracle 更加穩(wěn)定、運維成本也相對較低。

如上是做服務(wù)化中心帶來的好處，顯而易見。經(jīng)過一段時間的改造之后，技術(shù)架構(gòu)發(fā)生了很大變化，如下圖：

在整個技術(shù)架構(gòu)的最底層是 EDAS、DRDS、ONS 等組成的基礎(chǔ)應(yīng)用架構(gòu)。電商、物流、移動IM、地理信息、醫(yī)療等都有自己的能力且都把能力進(jìn)行開放，形成了IT共享業(yè)務(wù)架構(gòu)層，用來支撐上層的業(yè)務(wù)。一旦業(yè)務(wù)需要合作，下層的技術(shù)可以快速響應(yīng)。

例如，淘寶和滴滴從談合作到項目順利完成，只用了不到五天的時間。當(dāng)時是一個內(nèi)網(wǎng)打車軟件，用這個軟件打車可實現(xiàn)通過公司賬戶去叫車，省去貼發(fā)票環(huán)節(jié)。

這件事情，真正的凸顯出，技術(shù)可以幫助業(yè)務(wù)解決一些問題。雖然淘寶可能再也沒有 4.0 版本，但現(xiàn)在每套應(yīng)用系統(tǒng)都是為了未來而準(zhǔn)備。

企業(yè)級信息系統(tǒng)架構(gòu)的演進(jìn)

通過對阿里技術(shù)發(fā)展歷程的總結(jié)，我們發(fā)現(xiàn)這些經(jīng)過實踐得出來的技術(shù)架構(gòu)對一部分企業(yè)可以起到借鑒的作用。所以規(guī)劃成一個產(chǎn)品——企業(yè)級信息系統(tǒng)。

云計算時代，企業(yè)信息化演進(jìn)不僅僅是把 IT 系統(tǒng)搬到云上，而是讓業(yè)務(wù)與信息系統(tǒng)深度融合，改變業(yè)務(wù)運營和創(chuàng)新模式。

如下圖，是企業(yè)級信息系統(tǒng)的演進(jìn)過程：

把業(yè)務(wù)云化，從虛擬機(jī)模式轉(zhuǎn)變成基于分布式的互聯(lián)網(wǎng)架構(gòu)進(jìn)行重構(gòu)，重構(gòu)后給企業(yè)帶來的主要的價值是原來的一些效率問題得以解決。所以說，互聯(lián)網(wǎng)架構(gòu)平臺是企業(yè)云上演進(jìn)的使能平臺。

如下圖是企業(yè)級互聯(lián)網(wǎng)架構(gòu)平臺對應(yīng)的下層架構(gòu)：

最底層是基礎(chǔ)框架，主要涉及 EDAS、MQ 和 DRDS 三大產(chǎn)品：

•     EDAS 主要職責(zé)是業(yè)務(wù)應(yīng)用的編寫和發(fā)布。
•     MQ 是在異步解耦的過程中，用來做消息的編輯和保證事物的一致性。
•     有大量的用戶和數(shù)據(jù)后，由 DRDS 負(fù)責(zé)分散到各個應(yīng)用中去。

三個產(chǎn)品加起來，從上到下，很好地支撐業(yè)務(wù)的編寫、相互通信以及下層數(shù)據(jù)的建設(shè)。

CSB（能力開放平臺）的主要職責(zé)是將阿里的 negligible 對外開放運營、保證內(nèi)部數(shù)據(jù)的安全性和開放性，同時和現(xiàn)有的系統(tǒng)打通，進(jìn)入到系統(tǒng)中去。云化業(yè)務(wù)的能力部分，是和客戶一起設(shè)計構(gòu)建。整套系統(tǒng)到最后的核心關(guān)鍵點是成本、穩(wěn)定和效率。阿里在業(yè)務(wù)高速增長的這十幾年實踐中，積累了很多這三方面的經(jīng)驗。希望這些經(jīng)驗可以幫助一些企業(yè)少走彎路。

如下圖，是企業(yè)級互聯(lián)網(wǎng)架構(gòu)的關(guān)鍵特征：

隨著機(jī)器數(shù)量的增加，性能一定是線性增加、可靠性成指數(shù)型增長、運營成本要保持對數(shù)級上升。這些才是真正互聯(lián)網(wǎng)架構(gòu)的關(guān)鍵特征，如果系統(tǒng)不能很好的解決這些問題，它會是一個無法向上擴(kuò)展的系統(tǒng)，那么就無法滿足未來用戶的增長需要。

寫在最后

為什么會有這些互聯(lián)網(wǎng)系統(tǒng)？為什么會有這些互聯(lián)網(wǎng)架構(gòu)的特征？很簡單，因為阿里的軟件和服務(wù)最終是為用戶服務(wù)的，當(dāng)用戶成指數(shù)級增長時，系統(tǒng)沒有很好的擴(kuò)展性，就一定會死。

什么是企業(yè)級互聯(lián)網(wǎng)？就是如果光憑借互聯(lián)網(wǎng)模式往前走，成本、研發(fā)效率等都會成為問題?；谶^往經(jīng)驗，重新認(rèn)知思考后，希望通過軟件的方式讓互聯(lián)網(wǎng)業(yè)務(wù)寫的更容易，更能夠貼合企業(yè)高速增長的需求。

以上內(nèi)容根據(jù)王晶昱老師在 WOTA2017 “云服務(wù)架構(gòu)”專場的演講內(nèi)容整理。

[[198954]]

2008 年加入淘寶后在中間件和穩(wěn)定性平臺工作至今。目前負(fù)責(zé)阿里分布式數(shù)據(jù)庫，之前叫 TDDL，現(xiàn)在運用到阿里云上改名為 DRDS、阿里的分布式消息服務(wù)(Notify/MetaQ)，以及阿里企業(yè)級互聯(lián)網(wǎng)架構(gòu)平臺的新產(chǎn)品研發(fā)工作。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】

【責(zé)任編輯：wangxueyan TEL：（010）68476606】