這篇文章主要講述分布式時(shí)代和中間件相關(guān)知識(shí)硕舆，包括服務(wù)化斜棚、HSF俺亮、Notify和TDDL沥邻。同時(shí)里面有我們經(jīng)常遇見(jiàn)的編碼錯(cuò)誤等相關(guān)問(wèn)題平项，希望文章對(duì)你有所幫助!

一. 分布式時(shí)代

在系統(tǒng)發(fā)展的過(guò)程中赫舒，架構(gòu)師的眼光至關(guān)重要，作為程序員闽瓢，只要把功能實(shí)現(xiàn)即可接癌，但作為架構(gòu)師，要考慮系統(tǒng)的擴(kuò)展性扣讼、重用性缺猛，對(duì)于這種敏銳的感覺(jué)，有人說(shuō)是一種“代碼潔癖”。淘寶早期有幾個(gè)架構(gòu)師就具備了這種感覺(jué)荔燎，周銳虹開(kāi)發(fā)的Webx是一個(gè)擴(kuò)展性很強(qiáng)的框架耻姥，行癲在這個(gè)框架上插入了數(shù)據(jù)分庫(kù)路由的模塊、Session框架等有咨。在做淘寶后臺(tái)系統(tǒng)時(shí)琐簇，同樣需要這幾個(gè)模塊，行癲指導(dǎo)我把這些模塊單獨(dú)打成JAR包座享。

上面說(shuō)的都是比較小的復(fù)用模塊婉商，到2006年，我們做了一個(gè)商品類目屬性的改造渣叛，在類目中引入了屬性的概念丈秩。項(xiàng)目代號(hào)叫“泰山”，這是一個(gè)舉足輕重的項(xiàng)目淳衙，這個(gè)改變是一個(gè)劃時(shí)代的創(chuàng)新蘑秽。

在這之前三年時(shí)間內(nèi)，商品的分類都是按照樹(shù)狀一級(jí)一級(jí)的節(jié)點(diǎn)來(lái)分的滤祖，隨著商品數(shù)量增長(zhǎng)筷狼，類目也變得越來(lái)越深、復(fù)雜匠童。這樣埂材，買(mǎi)家如果查找一件商品，就要逐級(jí)打開(kāi)類目汤求，找商品之前要弄清商品的分類俏险。一個(gè)很嚴(yán)重的問(wèn)題，例如男裝里有T恤扬绪、T恤下面有耐克竖独、耐克有純棉的，女裝也有T恤挤牛、T恤下面還是有耐克莹痢、耐克下有純棉，那是先分男女裝墓赴，再分款式竞膳、品牌和材質(zhì)呢?還是先分品牌，再分款式诫硕、材質(zhì)和男女裝呢?

這時(shí)一燈說(shuō)品牌坦辟、款式、材質(zhì)等都可以叫做“屬性”章办，屬性是類似Tag(標(biāo)簽)的一個(gè)概念锉走，與類目相比更加靈活滨彻，這樣也縮減了類目的深度。這個(gè)思想解決了分類的難題!

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

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

有了類目屬性給運(yùn)營(yíng)工作帶來(lái)了很大的便利饮醇，我們知道淘寶的運(yùn)營(yíng)主要就是類目的運(yùn)營(yíng)它抱，什么季節(jié)推出什么商品，都要在類目屬性上做調(diào)整朴艰，讓買(mǎi)家容易找到观蓄。所屬商品的賣家要編輯一次自己的商品，如冬天把羽絨衣調(diào)整到女裝一級(jí)目錄下祠墅，但隨著商品量的增長(zhǎng)侮穿，賣家的工作量越來(lái)越大。

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

2.一種常見(jiàn)的編碼錯(cuò)誤

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

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

在這樣的惡性循環(huán)中，系統(tǒng)越來(lái)越腫碌廓，業(yè)務(wù)的耦合性越來(lái)越高(高內(nèi)聚传轰、低耦合)，開(kāi)發(fā)的效率越來(lái)越低谷婆。借用當(dāng)時(shí)較流行的一句話：“你寫(xiě)一段代碼慨蛙，編譯一下能通過(guò)，半個(gè)小時(shí)過(guò)去了;編譯一下沒(méi)通過(guò)纪挎，半天就過(guò)去了期贫。”在這種情況下异袄，系統(tǒng)出錯(cuò)的概率也逐步增長(zhǎng)通砍，這讓開(kāi)發(fā)人員苦不堪言。感覺(jué)現(xiàn)在很多公司招實(shí)習(xí)生都是這種感覺(jué)隙轻。

2007年年底的時(shí)候埠帕，研發(fā)部空降了一位從硅谷來(lái)的高管——空聞大師。他是一位溫厚的長(zhǎng)者玖绿，他告訴我們一切要以穩(wěn)定為中心敛瓷，所有影響系統(tǒng)穩(wěn)定的因素都要解決掉。例如：每做一個(gè)日常修改斑匪，都必須對(duì)整個(gè)系統(tǒng)回歸測(cè)試一遍;多個(gè)日常修改如果放在一個(gè)版本中呐籽，要是一個(gè)功能沒(méi)有測(cè)試通過(guò)，整個(gè)系統(tǒng)都不能發(fā)布蚀瘸。我們把這個(gè)叫做“火車模型”狡蝶，即任何一個(gè)乘客沒(méi)有上車，都不許發(fā)車贮勃。這樣做最直接的后果就是火車一直晚點(diǎn)贪惹，新功能上線更慢，我們能明顯感覺(jué)到業(yè)務(wù)放的不滿寂嘉，壓力非常大奏瞬。

現(xiàn)在回過(guò)頭來(lái)看枫绅，其實(shí)我們并沒(méi)有理解背后的思路。正是在這種要求下硼端，我們不得不開(kāi)始改變些東西并淋，例如：把回歸測(cè)試日常化珍昨，每天晚上都跑一遍整個(gè)系統(tǒng)的回歸县耽。

另外，在這種要求下镣典，我們不得不對(duì)這個(gè)超級(jí)復(fù)雜的系統(tǒng)做肢解和重構(gòu)兔毙，其中復(fù)用性最高的一個(gè)模塊：用戶信息模塊開(kāi)始拆分出來(lái)，我們叫它UIC(User Information Center)骆撇。在UIC中瞒御，它只處理最基礎(chǔ)的用戶信息操作，例如getUserById神郊、getUserByName等。

在另一方面趾唱，還有兩個(gè)新興的業(yè)務(wù)對(duì)系統(tǒng)基礎(chǔ)功能的拆分也提出了要求涌乳。在那時(shí)候，我們做了淘寶旅行(trip.taobao.com)和淘寶彩票(caipiao.taobao.com)兩個(gè)新業(yè)務(wù)甜癞，這兩個(gè)新業(yè)務(wù)在商品的展示和交易的流程上都跟主站的業(yè)務(wù)不一樣夕晓，機(jī)票是按照航班信息展示的，彩票是按照雙色球悠咱、數(shù)字和足球的賽程來(lái)展示的蒸辆。但用到的會(huì)員功能和交易功能是與主站差不多的，當(dāng)時(shí)做起來(lái)很糾結(jié)析既，因?yàn)槿绻谥髡局凶龉保瑫?huì)有一大半跟主站無(wú)關(guān)的東西，如果重新做一個(gè)眼坏，會(huì)有很多重復(fù)建設(shè)拂玻。

最終我們決定不再給主站添亂了，就另起爐灶做了兩個(gè)新的業(yè)務(wù)系統(tǒng)宰译，從查詢商品檐蚜、購(gòu)買(mǎi)商品、評(píng)價(jià)反饋沿侈、查看訂單這一整個(gè)流程都重新寫(xiě)了一套〈车冢現(xiàn)在在“我的淘寶”中查看交易記錄，還能發(fā)現(xiàn)“已買(mǎi)到的寶貝”中把機(jī)票和彩票另外列出來(lái)了缀拭，他們沒(méi)加入到普通訂單中咳短。

當(dāng)時(shí)如果已經(jīng)把會(huì)員填帽、交易、商品诲泌、評(píng)價(jià)這些模塊都拆分出來(lái)盲赊，就不用什么都重做一遍了。

到2008年初敷扫，整個(gè)主動(dòng)系統(tǒng)(有了機(jī)票哀蘑、彩票系統(tǒng)之后，把原來(lái)的系統(tǒng)叫做主站)的容量已經(jīng)達(dá)到了瓶頸葵第，商品數(shù)在1億個(gè)以上绘迁，PV在2.5億個(gè)以上，會(huì)員數(shù)超過(guò)了5000萬(wàn)個(gè)卒密。這時(shí)Oracle的連接池?cái)?shù)量都不夠用了缀台，數(shù)據(jù)庫(kù)的容量到了極限，即使上層系統(tǒng)加機(jī)器也無(wú)法繼續(xù)擴(kuò)容哮奇，我們只有把底層的基礎(chǔ)服務(wù)繼續(xù)拆分膛腐，從底層開(kāi)始擴(kuò)容，上層才能擴(kuò)展鼎俘，這才能容納未來(lái)三五年的增長(zhǎng)哲身。

于是我們啟動(dòng)了一個(gè)更大的項(xiàng)目，即把交易這個(gè)核心業(yè)務(wù)模塊拆分出來(lái)贸伐。

原來(lái)的淘寶交易除了跟商品管理耦合在一起勘天，還在支付寶和淘寶之間轉(zhuǎn)換，跟支付寶耦合在一起捉邢，這會(huì)導(dǎo)致系統(tǒng)很復(fù)雜脯丝，用戶體驗(yàn)也很不好。我們把交易的底層業(yè)務(wù)拆分出來(lái)伏伐，叫交易中心(TradeCenter宠进，TC)，所謂底層業(yè)務(wù)秘案，就如創(chuàng)建訂單砰苍、減庫(kù)存、修改訂單狀態(tài)等原子型的操作;交易的上層業(yè)務(wù)叫交易管理(TradeManager阱高，TM)例如拍下一件普通商品要對(duì)訂單赚导、庫(kù)存、物流進(jìn)行操作赤惊，拍下虛擬商品不需要對(duì)物流進(jìn)行操作吼旧，這些在TM中完成。

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

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

我們對(duì)這個(gè)項(xiàng)目取了一個(gè)很霸氣的名字——“五彩石”(女?huà)z煉石補(bǔ)天用的石頭)欲诺。這個(gè)系統(tǒng)重構(gòu)的工作非常驚險(xiǎn)，有人稱為“給一架高速飛行的飛機(jī)換發(fā)動(dòng)機(jī)”渺鹦。他們把淘寶的系統(tǒng)拆分成了如下架構(gòu)扰法。

其中，UIC和Forest在上文已說(shuō)過(guò)毅厚，TC塞颁、IC、SC分別是交易中心(Trade Center)吸耿、商品中心(Item Center)祠锣、店鋪中心(Shop Center)，這些中心級(jí)別的服務(wù)只提供原子級(jí)的業(yè)務(wù)邏輯咽安，如根據(jù)ID查找商品锤岸、創(chuàng)建交易、減少庫(kù)存等操作板乙。

再往上一次是業(yè)務(wù)系統(tǒng)TM(Trade Manager，交易業(yè)務(wù))拳氢、IM(Item Manager募逞，商品業(yè)務(wù))、SM(Shop Manager馋评，后來(lái)改名叫SS放接，即Shop System，店鋪業(yè)務(wù))留特、Detail(商品詳情)纠脾。

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

系統(tǒng)這么拆分的好處顯而易見(jiàn)苟蹈，拆分之后每個(gè)系統(tǒng)可以單獨(dú)部署，業(yè)務(wù)簡(jiǎn)單右核，方便擴(kuò)容;有大量可重用的模塊便于開(kāi)發(fā)新的業(yè)務(wù);能夠做到專人專事慧脱，讓技術(shù)人員更加專注于某一個(gè)領(lǐng)域。

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

另外，拆分之后的系統(tǒng)如何通信?這里需要兩種中間件系統(tǒng)鹊漠，一種是實(shí)時(shí)調(diào)用的中間件(淘寶的HSF主到，高性能服務(wù)框架)，一種是異步消息通知的中間件(淘寶的Notify)贸呢。另外镰烧，一個(gè)需要解決的問(wèn)題是用戶在A系統(tǒng)登錄后，到B系統(tǒng)的時(shí)候楞陷，用戶的登錄信息怎么保存?這又設(shè)計(jì)一個(gè)Session框架怔鳖。再者，還有一個(gè)軟件工程方面的問(wèn)題固蛾，這么多層的一套系統(tǒng)结执，怎么去測(cè)試它?

二. 中間件

1.HSF

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

集群：所有收銀員提供的都是收銀功能恃泪，每個(gè)收銀員都可以完成收款郑兴，可以認(rèn)為所有的收銀員構(gòu)成了一個(gè)集群”春酰互聯(lián)網(wǎng)集群會(huì)受限于調(diào)度情连、數(shù)據(jù)庫(kù)、機(jī)房等览效。

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

負(fù)載均衡：讓每個(gè)收銀臺(tái)排隊(duì)差不多長(zhǎng)州刽，設(shè)立小件通道空执、團(tuán)購(gòu)?fù)ǖ馈IP通道等穗椅，這些都可認(rèn)為是集群帶來(lái)的負(fù)載均衡的問(wèn)題辨绊，從技術(shù)層面上實(shí)現(xiàn)自然比生活中復(fù)雜得多。

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

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

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

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

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

服務(wù)的提供者啟動(dòng)時(shí)通過(guò)HSF框架向ConfigServer(類似超市的電視機(jī))注冊(cè)服務(wù)信息(接口丘喻、版本、超時(shí)時(shí)間念颈、序列化方式等)泉粉，ConfigServer上定義了所有可供調(diào)用的服務(wù)(同一個(gè)服務(wù)也可能有不同的版本);

服務(wù)調(diào)用者啟動(dòng)時(shí)向ConfigServer注冊(cè)對(duì)哪些服務(wù)感興趣(接口、版本)，當(dāng)服務(wù)提供者的信息變化時(shí)嗡靡，ConfigServer向趕興趣的服務(wù)調(diào)用者推送新的服務(wù)信息列表;調(diào)用者在調(diào)用時(shí)則根據(jù)服務(wù)信息的列表直接訪問(wèn)相應(yīng)的服務(wù)提供者跺撼，無(wú)須經(jīng)過(guò)ConfigServer。

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

在HSF的支持下蜜自，服務(wù)集群對(duì)調(diào)用者來(lái)說(shuō)是“統(tǒng)一”的菩貌，服務(wù)之間是“隔離”的，這保證了服務(wù)的擴(kuò)展性和應(yīng)用的統(tǒng)一性重荠。再加上HSF本身提供的“軟負(fù)載均衡”箭阶，服務(wù)層對(duì)應(yīng)用層來(lái)說(shuō)就是一片“私有云”了。

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

HSF是一個(gè)分布式的標(biāo)準(zhǔn)Service方式的RPC(RemoteProcedure Call Protocol滩届，遠(yuǎn)程過(guò)程調(diào)用協(xié)議)框架。Service的定義基于OSGI的方式被啼，通訊層采用TCP/IP協(xié)議帜消。

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

這個(gè)有點(diǎn)“五花八門(mén)”。對(duì)于類目的調(diào)用方式是Forest打包成一個(gè)JAR包命浴，在應(yīng)用啟動(dòng)時(shí)裝載到內(nèi)存中娄猫，僅這個(gè)JAR包所占用的內(nèi)存就有800MB之多(因?yàn)樘詫毜念惸繑?shù)據(jù)龐大)贱除，對(duì)于當(dāng)時(shí)一般只有2GB內(nèi)存的開(kāi)發(fā)機(jī)來(lái)說(shuō)，加載完類目信息后媳溺，機(jī)器運(yùn)行速度就非常慢月幌。對(duì)于用戶信息(UIC)來(lái)說(shuō)，一開(kāi)始調(diào)用方式是Hessian接口褂删，還有一些系統(tǒng)是通過(guò)WebService飞醉、Socket甚至是HTTP請(qǐng)求來(lái)相互調(diào)用的。

每種調(diào)用方式都涉及各種超時(shí)屯阀、信息的加解/密缅帘、參數(shù)的定義等問(wèn)題，由此可見(jiàn)难衰，在沒(méi)有HSF之前钦无，系統(tǒng)之間的調(diào)用是錯(cuò)綜復(fù)雜的。而隨著系統(tǒng)拆分得越來(lái)越多盖袭，必須由一個(gè)統(tǒng)一的中間層來(lái)處理這種問(wèn)題失暂，HSF就是在這種背景下誕生的。

2.Notify

HSF解決了服務(wù)調(diào)用的問(wèn)題鳄虱，我們?cè)偬岢鲆粋€(gè)很早就說(shuō)過(guò)的問(wèn)題：用戶在銀行的網(wǎng)關(guān)付錢(qián)后弟塞，銀行需要通知到支付寶，但銀行的系統(tǒng)不一定能發(fā)出通知;如果通知發(fā)出了拙已，不一定能通知到;如果通知到了决记，不一定不重復(fù)通知一遍。

這個(gè)狀況在支付寶持續(xù)了很長(zhǎng)時(shí)間倍踪，非常痛苦系宫。支付寶從淘寶剝離出來(lái)時(shí)，淘寶和支付寶之間的通信也面臨同樣的問(wèn)題建车，支付寶架構(gòu)師魯肅提出用MQ(Message Queue)的方式來(lái)解決這個(gè)問(wèn)題扩借，我負(fù)責(zé)淘寶這邊讀取消息的模塊。但消息數(shù)量上來(lái)后缤至，常常造成擁堵潮罪，消息的順序也會(huì)出錯(cuò)，系統(tǒng)掛掉消息也會(huì)掛掉领斥。

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

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

在“千島湖”項(xiàng)目和“五彩石”項(xiàng)目后今艺，淘寶系統(tǒng)拆分成了很多個(gè)，他們之間也需要類似的通知爵卒。例如虚缎，拍下一件商品，在交易管理系統(tǒng)中完成時(shí)钓株，它需要通知商品管理系統(tǒng)減少庫(kù)存实牡，同時(shí)旺旺服務(wù)系統(tǒng)發(fā)送旺旺提醒，通知物流系統(tǒng)上門(mén)取貨轴合，通知SNS系統(tǒng)分享訂單创坞，通知公安局的系統(tǒng)這是騙子等等。

用戶一次請(qǐng)求受葛，在底層系統(tǒng)可能產(chǎn)生10次的消息通知题涨。這一大堆的通知信息是異步調(diào)用的(如果同步，系統(tǒng)耦合在一起就達(dá)不到拆分的目的)总滩，這些消息通知需要一個(gè)強(qiáng)大的系統(tǒng)提供支持纲堵，從消息的數(shù)量級(jí)上看，比支付寶和淘寶之間的消息量又上了一個(gè)層次闰渔，于是按照類似的思路席函，一個(gè)更加強(qiáng)大的消息中間件系統(tǒng)就誕生了，它的名字叫做Notify澜建。在此我向大家推薦一個(gè)架構(gòu)學(xué)習(xí)交流群向挖。交流學(xué)習(xí)群號(hào)：897889510 里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring，MyBatis炕舵，Netty源碼分析何之，高并發(fā)、高性能咽筋、分布式溶推、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化奸攻、分布式架構(gòu)等這些成為架構(gòu)師必備的知識(shí)體系蒜危。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源，目前受益良多

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

NotifyServer在ConfigServer上注冊(cè)消息服務(wù)硝训，消息的客戶端通過(guò)ConfigServer訂閱消息服務(wù)响委。某個(gè)客戶端調(diào)用NotifyServer發(fā)送一條消息新思，NotifyServer負(fù)責(zé)把消息發(fā)送到所有訂閱這個(gè)消息的客戶端(參照HSF圖)。

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

NotifyServer可以水平擴(kuò)展山析，NotifyClient也可以水平擴(kuò)展堰燎，數(shù)據(jù)庫(kù)也可以水平擴(kuò)展。從理論上講笋轨，這個(gè)消息系統(tǒng)的吞吐量時(shí)沒(méi)有上限的秆剪，現(xiàn)在Notify系統(tǒng)每天承載了淘寶10億次以上的消息通知。

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

3.TDDL

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

前面講過(guò)淘寶很早就對(duì)數(shù)據(jù)進(jìn)行過(guò)分庫(kù)的處理，上層系統(tǒng)連接多個(gè)數(shù)據(jù)庫(kù)汤锨，中間有一個(gè)叫做DBRoute的路由來(lái)對(duì)數(shù)據(jù)進(jìn)行統(tǒng)一訪問(wèn)双抽。DBRoute對(duì)數(shù)據(jù)進(jìn)行多庫(kù)的操作、數(shù)據(jù)的整合闲礼，讓上層系統(tǒng)像操作一個(gè)數(shù)據(jù)庫(kù)一樣操作多個(gè)庫(kù)牍汹。隨著數(shù)據(jù)量的增長(zhǎng)，對(duì)于庫(kù)表的分發(fā)有了更高的要求柬泽。例如慎菲，你的商品數(shù)據(jù)到了百億級(jí)別時(shí)，任何一個(gè)庫(kù)都無(wú)法存放了锨并，于是分成2個(gè)露该、4個(gè)…1024個(gè)、2048個(gè)第煮。分成這么多解幼，數(shù)據(jù)能存放了闸拿，那怎么查詢它?

這時(shí)候，數(shù)據(jù)查詢的中間件就要能夠承擔(dān)這個(gè)重任了书幕，它對(duì)上層來(lái)說(shuō)，必須像查詢一個(gè)數(shù)據(jù)庫(kù)一樣來(lái)查詢數(shù)據(jù)揽趾，還要想查詢一個(gè)數(shù)據(jù)庫(kù)一樣快(每條查詢?cè)趲缀撩雰?nèi)完成)台汇，TDDL就承擔(dān)了這樣一個(gè)工作。

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

1).數(shù)據(jù)訪問(wèn)路由——將針對(duì)數(shù)據(jù)的讀寫(xiě)請(qǐng)求發(fā)送到最適合的地方

2).數(shù)據(jù)的多向非對(duì)稱復(fù)制——一次寫(xiě)入澄者，多點(diǎn)讀取

3).數(shù)據(jù)存儲(chǔ)的自由擴(kuò)展——不再受限于單臺(tái)機(jī)器的容量瓶頸與速度瓶頸笆呆，平滑遷移

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

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

“對(duì)一部分?jǐn)?shù)據(jù)庫(kù)使用MySQL”榕堰，DBA們的決策是這樣，于是分布式數(shù)據(jù)層的重?fù)?dān)就落到了華黎的頭上嫌套。當(dāng)時(shí)的需求如下：對(duì)外統(tǒng)一一切數(shù)據(jù)訪問(wèn)逆屡、支持緩存和文件存儲(chǔ)系統(tǒng)、能夠在Oracle和MySQL之間自由切換踱讨、支持搜索引擎魏蔗。

那么，如何實(shí)現(xiàn)分布式Join(連接)?(跨節(jié)點(diǎn)后簡(jiǎn)單Join就會(huì)變成M*N臺(tái)機(jī)器的合并勇蝙，代價(jià)太大)如何實(shí)現(xiàn)高速多維度查詢?如何實(shí)現(xiàn)分布式事務(wù)?

于是動(dòng)手我們自己做沫勿，名字叫Taobao Distributed Data Layer(TDDL，外號(hào)“頭都打了”)味混，學(xué)習(xí)開(kāi)源的Amoeba Proxy产雹。這就是TDDL 1.0時(shí)代。

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

最后希望文章對(duì)你有所幫助篮撑，如果文章有不足或錯(cuò)誤的地方，還請(qǐng)海涵!文章寫(xiě)到此處匆瓜，感覺(jué)讀后感還是會(huì)應(yīng)該以精簡(jiǎn)為主赢笨，下次寫(xiě)書(shū)籍讀后感盡量寫(xiě)成一篇，而不是大量的摘抄原文驮吱。希望大家購(gòu)買(mǎi)原書(shū)看看茧妒，非常不錯(cuò)~