這篇文章主要講述分布式時代和中間件相關(guān)知識，包括服務(wù)化、HSF、Notify和TDDL。同時里面有我們經(jīng)常遇見的編碼錯誤等相關(guān)問題，希望文章對你有所幫助！

一. 分布式時代

在系統(tǒng)發(fā)展的過程中，架構(gòu)師的眼光至關(guān)重要，作為程序員，只要把功能實現(xiàn)即可，但作為架構(gòu)師，要考慮系統(tǒng)的擴展性、重用性，對于這種敏銳的感覺，有人說是一種“代碼潔癖”。淘寶早期有幾個架構(gòu)師就具備了這種感覺，周銳虹開發(fā)的Webx是一個擴展性很強的框架，行癲在這個框架上插入了數(shù)據(jù)分庫路由的模塊、Session框架等。在做淘寶后臺系統(tǒng)時，同樣需要這幾個模塊，行癲指導(dǎo)我把這些模塊單獨打成JAR包。

上面說的都是比較小的復(fù)用模塊，到2006年，我們做了一個商品類目屬性的改造，在類目中引入了屬性的概念。項目代號叫“泰山”，這是一個舉足輕重的項目，這個改變是一個劃時代的創(chuàng)新。

在這之前三年時間內(nèi)，商品的分類都是按照樹狀一級一級的節(jié)點來分的，隨著商品數(shù)量增長，類目也變得越來越深、復(fù)雜。這樣，買家如果查找一件商品，就要逐級打開類目，找商品之前要弄清商品的分類。一個很嚴(yán)重的問題，例如男裝里有T恤、T恤下面有耐克、耐克有純棉的，女裝也有T恤、T恤下面還是有耐克、耐克下有純棉，那是先分男女裝，再分款式、品牌和材質(zhì)呢？還是先分品牌，再分款式、材質(zhì)和男女裝呢？

這時一燈說品牌、款式、材質(zhì)等都可以叫做“屬性”，屬性是類似Tag（標(biāo)簽）的一個概念，與類目相比更加靈活，這樣也縮減了類目的深度。這個思想解決了分類的難題！

從系統(tǒng)角度來看，我們建立了“屬性”這樣一個數(shù)據(jù)結(jié)構(gòu)，由于除了類目的子節(jié)點有屬性外，父節(jié)點也可能有屬性，于是類目屬性合起來也是一個結(jié)構(gòu)化的數(shù)據(jù)對象。把它獨立出來作為一個服務(wù)，叫做Catserver(Category Server)。跟類目屬性密切關(guān)聯(lián)的商品搜索功能獨立出來，叫做Hesper(金星)。Catserver和Hesper供淘寶的前后臺系統(tǒng)調(diào)用。

現(xiàn)在淘寶的商品類目屬性已經(jīng)是全球最大的，幾乎沒有什么類目的商品在淘寶上找不到（除違禁品），但最初的類目屬性改造完之后，缺乏屬性數(shù)據(jù)，尤其是數(shù)碼類。從哪里弄這些數(shù)據(jù)呢？我們跟“中關(guān)村在線”合作，拿到了很多數(shù)據(jù)。

有了類目屬性給運營工作帶來了很大的便利，我們知道淘寶的運營主要就是類目的運營，什么季節(jié)推出什么商品，都要在類目屬性上做調(diào)整，讓買家容易找到。所屬商品的賣家要編輯一次自己的商品，如冬天把羽絨衣調(diào)整到女裝一級目錄下，但隨著商品量的增長，賣家的工作量越來越大。

到了2008年，我們研究了超市里前后臺商品的分類，發(fā)現(xiàn)超市前后臺商品可以隨季節(jié)和關(guān)聯(lián)來調(diào)整擺放場景（例如著名的啤酒和尿布的關(guān)聯(lián)），后臺倉庫里要按照自然類目來存儲，二者密切關(guān)聯(lián)，卻又相互分開。淘寶前臺展示的是根據(jù)運營需要擺放商品的類目和屬性。改造后的類目屬性服務(wù)取名為Forest(森林，與類目屬性有點神似。Catserver還用于提供賣家授權(quán)、品牌服務(wù)、關(guān)鍵詞等相關(guān)服務(wù))。類目屬性的服務(wù)化是淘寶在系統(tǒng)服務(wù)化方面做的第一個探索。

2.一種常見的編碼錯誤

雖然個別架構(gòu)師具備了“代碼潔癖”，但淘寶前臺系統(tǒng)的業(yè)務(wù)量和代碼量還是呈爆炸式的增長。

業(yè)務(wù)方總在后面催，開發(fā)人員不夠就繼續(xù)招人，招來的人根本看不懂原來的業(yè)務(wù)，只好摸索著在“合適的地方”加上一些“合適的代碼”，看看運行起來像那么回事后，就發(fā)布上線。

在這樣的惡性循環(huán)中，系統(tǒng)越來越腫，業(yè)務(wù)的耦合性越來越高（高內(nèi)聚、低耦合），開發(fā)的效率越來越低。借用當(dāng)時較流行的一句話：“你寫一段代碼，編譯一下能通過，半個小時過去了；編譯一下沒通過，半天就過去了。”在這種情況下，系統(tǒng)出錯的概率也逐步增長，這讓開發(fā)人員苦不堪言。感覺現(xiàn)在很多公司招實習(xí)生都是這種感覺。

2007年年底的時候，研發(fā)部空降了一位從硅谷來的高管——空聞大師。他是一位溫厚的長者，他告訴我們一切要以穩(wěn)定為中心，所有影響系統(tǒng)穩(wěn)定的因素都要解決掉。例如：每做一個日常修改，都必須對整個系統(tǒng)回歸測試一遍；多個日常修改如果放在一個版本中，要是一個功能沒有測試通過，整個系統(tǒng)都不能發(fā)布。我們把這個叫做“火車模型”，即任何一個乘客沒有上車，都不許發(fā)車。這樣做最直接的后果就是火車一直晚點，新功能上線更慢，我們能明顯感覺到業(yè)務(wù)放的不滿，壓力非常大。

現(xiàn)在回過頭來看，其實我們并沒有理解背后的思路。正是在這種要求下，我們不得不開始改變些東西，例如：把回歸測試日常化，每天晚上都跑一遍整個系統(tǒng)的回歸。

另外，在這種要求下，我們不得不對這個超級復(fù)雜的系統(tǒng)做肢解和重構(gòu)，其中復(fù)用性最高的一個模塊：用戶信息模塊開始拆分出來，我們叫它UIC（User Information Center）。在UIC中，它只處理最基礎(chǔ)的用戶信息操作，例如getUserById、getUserByName等。

在另一方面，還有兩個新興的業(yè)務(wù)對系統(tǒng)基礎(chǔ)功能的拆分也提出了要求。在那時候，我們做了淘寶旅行（trip.taobao.com）和淘寶彩票（caipiao.taobao.com）兩個新業(yè)務(wù)，這兩個新業(yè)務(wù)在商品的展示和交易的流程上都跟主站的業(yè)務(wù)不一樣，機票是按照航班信息展示的，彩票是按照雙色球、數(shù)字和足球的賽程來展示的。但用到的會員功能和交易功能是與主站差不多的，當(dāng)時做起來很糾結(jié)，因為如果在主站中做，會有一大半跟主站無關(guān)的東西，如果重新做一個，會有很多重復(fù)建設(shè)。

最終我們決定不再給主站添亂了，就另起爐灶做了兩個新的業(yè)務(wù)系統(tǒng)，從查詢商品、購買商品、評價反饋、查看訂單這一整個流程都重新寫了一套。現(xiàn)在在“我的淘寶”中查看交易記錄，還能發(fā)現(xiàn)“已買到的寶貝”中把機票和彩票另外列出來了，他們沒加入到普通訂單中。

當(dāng)時如果已經(jīng)把會員、交易、商品、評價這些模塊都拆分出來，就不用什么都重做一遍了。

到2008年初，整個主動系統(tǒng)（有了機票、彩票系統(tǒng)之后，把原來的系統(tǒng)叫做主站）的容量已經(jīng)達到了瓶頸，商品數(shù)在1億個以上，PV在2.5億個以上，會員數(shù)超過了5000萬個。這時Oracle的連接池數(shù)量都不夠用了，數(shù)據(jù)庫的容量到了極限，即使上層系統(tǒng)加機器也無法繼續(xù)擴容，我們只有把底層的基礎(chǔ)服務(wù)繼續(xù)拆分，從底層開始擴容，上層才能擴展，這才能容納未來三五年的增長。

于是我們啟動了一個更大的項目，即把交易這個核心業(yè)務(wù)模塊拆分出來。

原來的淘寶交易除了跟商品管理耦合在一起，還在支付寶和淘寶之間轉(zhuǎn)換，跟支付寶耦合在一起，這會導(dǎo)致系統(tǒng)很復(fù)雜，用戶體驗也很不好。我們把交易的底層業(yè)務(wù)拆分出來，叫交易中心（TradeCenter，TC），所謂底層業(yè)務(wù)，就如創(chuàng)建訂單、減庫存、修改訂單狀態(tài)等原子型的操作；交易的上層業(yè)務(wù)叫交易管理（TradeManager，TM）例如拍下一件普通商品要對訂單、庫存、物流進行操作，拍下虛擬商品不需要對物流進行操作，這些在TM中完成。

#p#

3.業(yè)務(wù)模塊化

類目屬性、用戶中心、交易中心，隨著這些模塊逐步拆分和服務(wù)化改造，我們在系統(tǒng)架構(gòu)方面也積累了不少經(jīng)驗。到2008年年底就做了一個更大的項目，把淘寶所有的業(yè)務(wù)都模塊化，這是繼2004年從LAMP架構(gòu)到Java架構(gòu)之間的第二次脫胎換骨。

我們對這個項目取了一個很霸氣的名字——“五彩石”（女媧煉石補天用的石頭）。這個系統(tǒng)重構(gòu)的工作非常驚險，有人稱為“給一架高速飛行的飛機換發(fā)動機”。他們把淘寶的系統(tǒng)拆分成了如下架構(gòu)。

其中，UIC和Forest在上文已說過，TC、IC、SC分別是交易中心（Trade Center）、商品中心（Item Center）、店鋪中心（Shop Center），這些中心級別的服務(wù)只提供原子級的業(yè)務(wù)邏輯，如根據(jù)ID查找商品、創(chuàng)建交易、減少庫存等操作。

再往上一次是業(yè)務(wù)系統(tǒng)TM（Trade Manager，交易業(yè)務(wù)）、IM（Item Manager，商品業(yè)務(wù)）、SM（Shop Manager，后來改名叫SS，即Shop System，店鋪業(yè)務(wù)）、Detail（商品詳情）。

拆分之后，系統(tǒng)之間的交互關(guān)系變得非常復(fù)雜。

系統(tǒng)這么拆分的好處顯而易見，拆分之后每個系統(tǒng)可以單獨部署，業(yè)務(wù)簡單，方便擴容；有大量可重用的模塊便于開發(fā)新的業(yè)務(wù)；能夠做到專人專事，讓技術(shù)人員更加專注于某一個領(lǐng)域。

這樣要解決的問題也很明顯，拆分后，系統(tǒng)之間還是必須要打交道的，越往底層的系統(tǒng)，調(diào)用它的客戶越多，這要求底層系統(tǒng)必須具有超大規(guī)模的容量和非常高的可用性。

另外，拆分之后的系統(tǒng)如何通信？這里需要兩種中間件系統(tǒng)，一種是實時調(diào)用的中間件（淘寶的HSF，高性能服務(wù)框架），一種是異步消息通知的中間件（淘寶的Notify）。另外，一個需要解決的問題是用戶在A系統(tǒng)登錄后，到B系統(tǒng)的時候，用戶的登錄信息怎么保存？這又設(shè)計一個Session框架。再者，還有一個軟件工程方面的問題，這么多層的一套系統(tǒng)，怎么去測試它？

二. 中間件

1.HSF

其實互聯(lián)網(wǎng)網(wǎng)站發(fā)展過程類似于超市經(jīng)營（此處省略超市銷售收銀的例子，可以想象下沃爾瑪排隊購物付款的場景吧），只是在技術(shù)層面用其他名詞來表達而已，例如：有集群、分工、負載均衡、根據(jù)QoS分配資源等。

集群：所有收銀員提供的都是收銀功能，每個收銀員都可以完成收款，可以認為所有的收銀員構(gòu)成了一個集群?；ヂ?lián)網(wǎng)集群會受限于調(diào)度、數(shù)據(jù)庫、機房等。

分工：收銀員和打掃衛(wèi)生的人分開，這種分工容易解決，而這種分工在互聯(lián)網(wǎng)中是一項重要而復(fù)雜的技術(shù)，涉及的主要有按功能和數(shù)據(jù)庫的不同拆分系統(tǒng)等。如何拆分和拆分后如何交互是需要面臨的兩個挑戰(zhàn)。隱藏會有高性能通信框架、SOA平臺、消息中間件、分布式數(shù)據(jù)層等基礎(chǔ)產(chǎn)品的誕生。

負載均衡：讓每個收銀臺排隊差不多長，設(shè)立小件通道、團購?fù)ǖ馈IP通道等，這些都可認為是集群帶來的負載均衡的問題，從技術(shù)層面上實現(xiàn)自然比生活中復(fù)雜得多。

根據(jù)QoS(Quality of Service，服務(wù)質(zhì)量)分配資源：部分員工僅在晚上加班的機制在生活中不難實現(xiàn)，但對互聯(lián)網(wǎng)應(yīng)用而言，就是一件復(fù)雜而且極具挑戰(zhàn)的事。

而且生活中面對用戶增長的情況下，想出這些招應(yīng)該不難。不過要掌握以上四點涉及的技術(shù)就相當(dāng)復(fù)雜了，而且互聯(lián)網(wǎng)中涉及的其他很多技術(shù)還沒有在這個例子中展現(xiàn)出來。例如緩存、CDN等優(yōu)化手段；運轉(zhuǎn)狀況監(jiān)測、功能降級、資源劣化、流控等可用性手段；自建機房、硬件組裝等成本控制手段。因此，構(gòu)建一個互聯(lián)網(wǎng)網(wǎng)站確實是不容易的，技術(shù)含量十足，當(dāng)然，經(jīng)營一家超市也不簡單。

服務(wù)拆分之后，如何取得我需要的服務(wù)呢？

在“電視機”上，把每個集群能提供的服務(wù)顯示出來。你不需要關(guān)心哪個人為你服務(wù)，當(dāng)你有需要的時候，頭頂?shù)碾娨暀C會告訴你哪個服務(wù)在哪個區(qū)域。當(dāng)你去到這個區(qū)域時，系統(tǒng)會給你找到一個最快的服務(wù)通道。

這就是HSF（High-Speed Service Framework）的設(shè)計思想：

服務(wù)的提供者啟動時通過HSF框架向ConfigServer（類似超市的電視機）注冊服務(wù)信息（接口、版本、超時時間、序列化方式等），ConfigServer上定義了所有可供調(diào)用的服務(wù)（同一個服務(wù)也可能有不同的版本）；

服務(wù)調(diào)用者啟動時向ConfigServer注冊對哪些服務(wù)感興趣（接口、版本），當(dāng)服務(wù)提供者的信息變化時，ConfigServer向趕興趣的服務(wù)調(diào)用者推送新的服務(wù)信息列表；調(diào)用者在調(diào)用時則根據(jù)服務(wù)信息的列表直接訪問相應(yīng)的服務(wù)提供者，無須經(jīng)過ConfigServer。

我們注意ConfigServer并不會把服務(wù)提供者的IP地址推送給服務(wù)的調(diào)用者，HSF框架會根據(jù)負載狀況來選擇具體的服務(wù)器，返回結(jié)果給調(diào)用者，這不僅統(tǒng)一了服務(wù)調(diào)用的方式，也實現(xiàn)了“軟負載均衡”。平時ConfigServer通過和服務(wù)提供者的心跳來感應(yīng)服務(wù)提供者的存活狀態(tài)。

在HSF的支持下，服務(wù)集群對調(diào)用者來說是“統(tǒng)一”的，服務(wù)之間是“隔離”的，這保證了服務(wù)的擴展性和應(yīng)用的統(tǒng)一性。再加上HSF本身提供的“軟負載均衡”，服務(wù)層對應(yīng)用層來說就是一片“私有云”了。

HSF框架以SAR包的方式部署到Jboss、Jetty或Tomcat下，在應(yīng)用啟動時，HSF（High-Speed Service Framework，在開發(fā)團隊內(nèi)部有一些人稱HSF為“好舒服”）服務(wù)隨機啟用。HSF旨在為淘寶的應(yīng)用提供一個分布式的服務(wù)框架，HSF從分布式應(yīng)用層面以及統(tǒng)一的發(fā)布/調(diào)用方式層面為大家提供支持，更容易地開發(fā)分布式應(yīng)用或使用公用功能模塊，而不用考慮分布式領(lǐng)域中的各種細節(jié)技術(shù)，例如：遠程通訊、性能損耗、調(diào)用的透明化、同步異步調(diào)用的問題。

HSF是一個分布式的標(biāo)準(zhǔn)Service方式的RPC（RemoteProcedure Call Protocol，遠程過程調(diào)用協(xié)議）框架。Service的定義基于OSGI的方式，通訊層采用TCP/IP協(xié)議。

HSF系統(tǒng)目前每天承擔(dān)300億次以上的服務(wù)調(diào)用，一些讀者可能會疑問：既然淘寶的服務(wù)化是漸進式的，那么在HSF出現(xiàn)之前，系統(tǒng)之間的調(diào)用采用什么方式呢？

這個有點“五花八門”。對于類目的調(diào)用方式是Forest打包成一個JAR包，在應(yīng)用啟動時裝載到內(nèi)存中，僅這個JAR包所占用的內(nèi)存就有800MB之多（因為淘寶的類目數(shù)據(jù)龐大），對于當(dāng)時一般只有2GB內(nèi)存的開發(fā)機來說，加載完類目信息后，機器運行速度就非常慢。對于用戶信息（UIC）來說，一開始調(diào)用方式是Hessian接口，還有一些系統(tǒng)是通過WebService、Socket甚至是HTTP請求來相互調(diào)用的。

每種調(diào)用方式都涉及各種超時、信息的加解/密、參數(shù)的定義等問題，由此可見，在沒有HSF之前，系統(tǒng)之間的調(diào)用是錯綜復(fù)雜的。而隨著系統(tǒng)拆分得越來越多，必須由一個統(tǒng)一的中間層來處理這種問題，HSF就是在這種背景下誕生的。

#p#

2.Notify

HSF解決了服務(wù)調(diào)用的問題，我們再提出一個很早就說過的問題：用戶在銀行的網(wǎng)關(guān)付錢后，銀行需要通知到支付寶，但銀行的系統(tǒng)不一定能發(fā)出通知；如果通知發(fā)出了，不一定能通知到；如果通知到了，不一定不重復(fù)通知一遍。

這個狀況在支付寶持續(xù)了很長時間，非常痛苦。支付寶從淘寶剝離出來時，淘寶和支付寶之間的通信也面臨同樣的問題，支付寶架構(gòu)師魯肅提出用MQ（Message Queue）的方式來解決這個問題，我負責(zé)淘寶這邊讀取消息的模塊。但消息數(shù)量上來后，常常造成擁堵，消息的順序也會出錯，系統(tǒng)掛掉消息也會掛掉。

然后魯肅提出做一個系統(tǒng)框架上的解決方案，把要發(fā)出的通知存到數(shù)據(jù)庫中，如果實時發(fā)送失敗，再用一個時間程序來周期性地發(fā)送這些通知，系統(tǒng)記錄下消息中間狀態(tài)和時間戳，這樣就保證了消息一定能發(fā)出，也一定能通知到，且通知帶有時間順序，甚至可以實現(xiàn)失去性的操作。

（PS：這個技術(shù)感覺以前做Android類似微信的隨手拍軟件時非常適用）

在“千島湖”項目和“五彩石”項目后，淘寶系統(tǒng)拆分成了很多個，他們之間也需要類似的通知。例如，拍下一件商品，在交易管理系統(tǒng)中完成時，它需要通知商品管理系統(tǒng)減少庫存，同時旺旺服務(wù)系統(tǒng)發(fā)送旺旺提醒，通知物流系統(tǒng)上門取貨，通知SNS系統(tǒng)分享訂單，通知公安局的系統(tǒng)這是騙子等等。

用戶一次請求，在底層系統(tǒng)可能產(chǎn)生10次的消息通知。這一大堆的通知信息是異步調(diào)用的（如果同步，系統(tǒng)耦合在一起就達不到拆分的目的），這些消息通知需要一個強大的系統(tǒng)提供支持，從消息的數(shù)量級上看，比支付寶和淘寶之間的消息量又上了一個層次，于是按照類似的思路，一個更加強大的消息中間件系統(tǒng)就誕生了，它的名字叫做Notify。

Notify是一個分布式的消息中間件系統(tǒng)，支持消息的訂閱、發(fā)送和消費，其架構(gòu)圖如下所示：

NotifyServer在ConfigServer上注冊消息服務(wù)，消息的客戶端通過ConfigServer訂閱消息服務(wù)。某個客戶端調(diào)用NotifyServer發(fā)送一條消息，NotifyServer負責(zé)把消息發(fā)送到所有訂閱這個消息的客戶端（參照HSF圖）。

為了保證消息一定能發(fā)出，且對方一定能收到，消息數(shù)據(jù)本身就需要記錄下來，這些信息存放在數(shù)據(jù)庫中。由于消息具有中間狀態(tài)（已發(fā)送、未發(fā)送等），應(yīng)用系統(tǒng)通過Notify可以實現(xiàn)分布式事物——BASE（基本可用Basically Available、軟狀態(tài)Soft State、最終一致Eventually Consistent）。

NotifyServer可以水平擴展，NotifyClient也可以水平擴展，數(shù)據(jù)庫也可以水平擴展。從理論上講，這個消息系統(tǒng)的吞吐量時沒有上限的，現(xiàn)在Notify系統(tǒng)每天承載了淘寶10億次以上的消息通知。

下圖展示了創(chuàng)建一筆交易后，TC（交易中心）向Notify發(fā)送一條消息，后續(xù)Notify所完成的一系列消息通知。

3.TDDL

有了HSF和Notify的支持，在應(yīng)用級別中，整個淘寶網(wǎng)的系統(tǒng)可以拆分了，還有一個制約系統(tǒng)規(guī)模的更重要的因素就是數(shù)據(jù)庫，也必須拆分。

前面講過淘寶很早就對數(shù)據(jù)進行過分庫的處理，上層系統(tǒng)連接多個數(shù)據(jù)庫，中間有一個叫做DBRoute的路由來對數(shù)據(jù)進行統(tǒng)一訪問。DBRoute對數(shù)據(jù)進行多庫的操作、數(shù)據(jù)的整合，讓上層系統(tǒng)像操作一個數(shù)據(jù)庫一樣操作多個庫。隨著數(shù)據(jù)量的增長，對于庫表的分發(fā)有了更高的要求。例如，你的商品數(shù)據(jù)到了百億級別時，任何一個庫都無法存放了，于是分成2個、4個…1024個、2048個。分成這么多，數(shù)據(jù)能存放了，那怎么查詢它？

這時候，數(shù)據(jù)查詢的中間件就要能夠承擔(dān)這個重任了，它對上層來說，必須像查詢一個數(shù)據(jù)庫一樣來查詢數(shù)據(jù)，還要想查詢一個數(shù)據(jù)庫一樣快（每條查詢在幾毫秒內(nèi)完成），TDDL就承擔(dān)了這樣一個工作。

另外，加上數(shù)據(jù)的備份、復(fù)制、主備切換等功能，這一套系統(tǒng)都在TDDL中完成。在外面有些系統(tǒng)也用DAL（數(shù)據(jù)訪問層）這個概念來命名這個中間件。TDDL實現(xiàn)了下面三個主要的特性：

1).數(shù)據(jù)訪問路由——將針對數(shù)據(jù)的讀寫請求發(fā)送到最適合的地方

2).數(shù)據(jù)的多向非對稱復(fù)制——一次寫入，多點讀取

3).數(shù)據(jù)存儲的自由擴展——不再受限于單臺機器的容量瓶頸與速度瓶頸，平滑遷移

下圖展示了TDDL所處的位置：

大家逐漸發(fā)現(xiàn)，如果按照業(yè)務(wù)的發(fā)展規(guī)模和速度，那么使用高端存儲和小型機的Oracle存儲的成本將難以控制，于是降低成本就成了必然。如何能夠在不影響業(yè)務(wù)正常發(fā)展的前提下，解決成本問題呢？

“對一部分數(shù)據(jù)庫使用MySQL”，DBA們的決策是這樣，于是分布式數(shù)據(jù)層的重擔(dān)就落到了華黎的頭上。當(dāng)時的需求如下：對外統(tǒng)一一切數(shù)據(jù)訪問、支持緩存和文件存儲系統(tǒng)、能夠在Oracle和MySQL之間自由切換、支持搜索引擎。

那么，如何實現(xiàn)分布式Join（連接）？（跨節(jié)點后簡單Join就會變成M*N臺機器的合并，代價太大）如何實現(xiàn)高速多維度查詢？如何實現(xiàn)分布式事務(wù)？

于是動手我們自己做，名字叫Taobao Distributed Data Layer（TDDL，外號“頭都打了”），學(xué)習(xí)開源的Amoeba Proxy。這就是TDDL 1.0時代。

粗略統(tǒng)計下來，TDDL已經(jīng)走過了4年時間，滿足了近700個業(yè)務(wù)應(yīng)用的使用需求。其中有交易商品評價用戶等核心數(shù)據(jù)，也有不那么有名的中小型應(yīng)用。量變產(chǎn)生質(zhì)變，如何能夠更好地幫助這些業(yè)務(wù)以更低的成本完成業(yè)務(wù)需求，將成為數(shù)據(jù)層未來最重要的挑戰(zhàn)。

最后希望文章對你有所幫助，如果文章有不足或錯誤的地方，還請海涵！文章寫到此處，感覺讀后感還是會應(yīng)該以精簡為主，下次寫書籍讀后感盡量寫成一篇，而不是大量的摘抄原文。希望大家購買原書看看，非常不錯~