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

一. 分布式時代

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

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

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

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

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

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

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

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

2.一種常見的編碼錯誤

雖然個別架構師具備了“代碼潔癖”，但淘寶前臺系統的業務量和代碼量還是呈爆炸式的增長。

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

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

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

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

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

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

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

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

 

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

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

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

#p#

3.業務模塊化

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

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

 

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

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

拆分之后，系統之間的交互關系變得非常復雜。

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

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

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

二. 中間件

1.HSF

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

集群：所有收銀員提供的都是收銀功能，每個收銀員都可以完成收款，可以認為所有的收銀員構成了一個集群。互聯網集群會受限于調度、數據庫、機房等。

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

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

根據QoS(Quality of Service，服務質量)分配資源：部分員工僅在晚上加班的機制在生活中不難實現，但對互聯網應用而言，就是一件復雜而且極具挑戰的事。

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

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

在“電視機”上，把每個集群能提供的服務顯示出來。你不需要關心哪個人為你服務，當你有需要的時候，頭頂的電視機會告訴你哪個服務在哪個區域。當你去到這個區域時，系統會給你找到一個最快的服務通道。

 

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

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

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

我們注意ConfigServer并不會把服務提供者的IP地址推送給服務的調用者，HSF框架會根據負載狀況來選擇具體的服務器，返回結果給調用者，這不僅統一了服務調用的方式，也實現了“軟負載均衡”。平時ConfigServer通過和服務提供者的心跳來感應服務提供者的存活狀態。

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

 

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

 

HSF是一個分布式的標準Service方式的RPC（RemoteProcedure Call Protocol，遠程過程調用協議）框架。Service的定義基于OSGI的方式，通訊層采用TCP/IP協議。

HSF系統目前每天承擔300億次以上的服務調用，一些讀者可能會疑問：既然淘寶的服務化是漸進式的，那么在HSF出現之前，系統之間的調用采用什么方式呢？

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

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

#p#

2.Notify

 

HSF解決了服務調用的問題，我們再提出一個很早就說過的問題：用戶在銀行的網關付錢后，銀行需要通知到支付寶，但銀行的系統不一定能發出通知；如果通知發出了，不一定能通知到；如果通知到了，不一定不重復通知一遍。

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

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

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

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

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

Notify是一個分布式的消息中間件系統，支持消息的訂閱、發送和消費，其架構圖如下所示：

 

NotifyServer在ConfigServer上注冊消息服務，消息的客戶端通過ConfigServer訂閱消息服務。某個客戶端調用NotifyServer發送一條消息，NotifyServer負責把消息發送到所有訂閱這個消息的客戶端（參照HSF圖）。

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

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

下圖展示了創建一筆交易后，TC（交易中心）向Notify發送一條消息，后續Notify所完成的一系列消息通知。

 

 

3.TDDL

有了HSF和Notify的支持，在應用級別中，整個淘寶網的系統可以拆分了，還有一個制約系統規模的更重要的因素就是數據庫，也必須拆分。

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

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

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

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

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

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

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

 

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

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

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

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

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

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