轉自：http://blog.sina.com.cn/s/blog_6332199701013c3t.html
淘寶技術發展（分佈式時代：服務化）
標籤：
雜談 |
在系統發展的過程中，架構師的眼光至關重要，作爲程序員，把功能實現即可，但作爲架構師，要考慮系統的擴展性、重用性，這種敏銳的感覺，有人說是一種代碼潔癖。淘寶早期有幾個架構師具備了這種感覺。一指開發的Webx是一個擴展性很強的框架，行癲在這個框架上插入了數據分庫路由的模塊、session框架等等。在做淘寶後臺系統的時候，同樣需要這幾個模塊，行癲指導我把這些模塊單獨打成了jar包。另外在做淘寶機票、彩票系統的時候，頁面端也有很多東西需要複用，最直觀的是頁頭和頁腳，一開始我們每個系統裏面複製了一份過去，但奇妙的是，那段時間頁腳要經常修改，例如把“雅虎中國”改成“中國雅虎”，過一段時間又加了一個“口碑網”，再過一段時間變成了“雅虎口碑”，最後又變成了“中國雅虎”，每個系統都改一遍，折騰啊。後來我就把這部分velocity模版單獨拿出來了，做成了公用的模塊。
上面這些都是比較小的複用模塊，到2006年我們做了一個商品類目屬性的改造，在類目裏面引入屬性的概念。項目的代號叫做“泰山”，如同它的名字，這是一個舉足輕重的項目，這個改變是一個劃時代的創新。在這之前的三年時間內，商品的分類都是按照樹狀的一級一級的節點來分的，隨着商品數量的增長，類目也變得越來越深，越來越複雜，這帶給買家的就是查找一件商品要逐級類目點開，找商品之前要懂商品的分類。而淘寶運營部門管理類目的小二也發現一個很嚴重的問題——例如男裝裏面有T恤、T恤下面有耐克、耐克有純棉的，女裝裏面也有T恤、T恤下面還是有耐克、耐克下面依然有純棉的，那是先分男女裝再分款式再分品牌再分材質呢？還是先分品牌再分款式再分材質再分男女呢？暈倒了。這時候，一位大俠出來了——一燈，他說品牌、款式、材質這種東東可以叫做“屬性”，屬性是類似tag的一個概念，與類目相比更加離散，更加靈活，這樣也縮減了類目的深度。這個思想的提出，一舉解決了分類的難題！從系統的角度來看，我們建立了“屬性”這樣一個數據結構，由於除了類目的子節點有屬性，父節點也有可能有屬性，於是類目屬性合起來也是一個結構化的數據對象。這個做出來之後我們把它獨立出來作爲一個服務，叫做catserver（category server）。跟類目屬性密切關聯的商品搜索功能，獨立出來，叫做hesper（金星），catserver和hesper供淘寶的前後臺系統調用。
現在淘寶的商品類目屬性已經是地球上最大的了，幾乎沒有什麼類目的商品在淘寶上找不到（除了違禁的），但最初類目屬性改造完之後，我們很缺屬性數據，尤其是數碼類的最缺。那從哪裏弄這些數據呢親？我們跟“中關村在線”合作，拿到了很多數據，那個時候，很多商品屬性信息的後邊標註着：“來自中關村在線”。有了類目屬性，給運營的工作帶來很大的便利，我們知道淘寶的運營主要就是類目的運營，什麼季節推什麼商品，都要在類目屬性上面做調整，讓買家更容易找到。例如夏天我要用戶在女裝一級類目下就標出來材質是不是蕾絲的、是不是純棉的，冬天卻要把羽絨衣調到女裝一級類目下，流行什麼就要把什麼商品往更高級的類目調整。這樣類目和屬性要經常調整，隨之而來的問題就顯現了——調整到哪個類目，那類商品的賣家就要編輯一次自己的商品，隨着商品量的增長，賣家的工作量越來越大，然後我們就發現賣家受不了啦。到了2008年，我們研究了超市裏面前後臺商品的分類，發現超市前臺商品可以隨季節和關聯來調整擺放場景（例如著名的啤酒和尿布的關聯），後臺倉庫裏面要按照自然類目來存儲，二者密切關聯卻又相互分開。然後我們就把前後臺類目分開了，這樣賣家發佈商品選擇的是自然類目和屬性，淘寶前臺展示的是根據運營需要而擺放的商品的類目和屬性。改造後的類目屬性服務取名叫做forest（森林，跟類目屬性有點神似。catserver還在，提供賣家授權、品牌服務、關鍵詞等相關的服務）。類目屬性的服務化，是淘寶在系統服務化方面做的第一個探索。
雖然個別架構師具備了代碼潔癖，但淘寶前臺系統的業務量和代碼量還是爆炸式的增長了起來。業務方總在後面催，開發人員不夠了就繼續招人，招來的人根本看不懂原來的業務，只好摸索着在“合適的地方”加一些“合適的代碼”，看看運行起來像那麼回事，就發佈上線了。在這樣的惡性循環中，系統越來越臃腫，業務的耦合性越來越高，開發的效率越來越低。借用當時比較流行的一句話“寫一段代碼，編譯一下能通過，半個小時就過去了；編譯一下沒通過，半天就過去了。”在這種情況下，系統出錯的概率也逐步增長，常常是你改了商品相關的某些代碼，發現交易出問題了，甚至你改了論壇上的某些代碼，旺旺出問題了。這讓開發人員苦不堪言，而業務方還認爲這幫人幹活越來越慢了。
大概是在2007年底的時候，研發部空降了一位從硅谷來的高管，空聞大師。空聞是一位溫厚的長者，他告訴我們一切要以穩定爲中心，所有影響系統穩定的因素都要解決掉。例如每做一個日常修改，都必須整個系統迴歸測試一遍；多個日常修改如果放在一個版本里面，要是一個功能沒有測試通過，整個系統都不能發佈。我們把這個叫做“火車模型”，任何一個乘客沒有上車，都不許發車。這樣做的最直接後果就是火車一直晚點，新功能上線更慢了，我們能明顯的感覺到業務方的不滿，空聞的壓力肯定非常大。當時我都不理解這種一刀切的做法，爲了穩定犧牲了發展的速度，這跟某Party的“穩定壓倒一切”有什麼分別？
但是到現在回過頭來看看，其實我們並沒有理解背後的思路。正是在這種要求下，我們不得不開始改變一些東西，例如把迴歸測試日常化，每天晚上都跑一遍整個系統的迴歸。還有就是在這種要求下，我們不得不對這個超級複雜的系統做肢解和重構，其中複用性最高的一個模塊——用戶信息模塊開始拆分出來了，我們叫它UIC（user information center）。在UIC裏面，它只處理最基礎的用戶信息操作，例如getUserById、getUserByName等等。
在另外一個方面，還有兩個新興的業務，也對系統基礎功能的拆分提出了要求。在那個時候，我們做了淘寶旅行（trip.taobao.com）和淘寶彩票（caipiao.taobao.com）兩個新業務，這兩個新業務在商品的展示和交易的流程上都跟主站的業務不一樣，機票是按照航班的信息展示的，彩票是按照雙色球、數字和足球的賽程來展示的。但用到的會員的功能和交易的功能是跟主站差不多的，當時做的時候就很糾結，在主站裏面做的話，會有一大半跟主站無關的東西，重新做一個的話，會有很多重複建設。最終我們決定不再給主站添亂了，就另起爐竈做了兩個新的業務系統。從查詢商品、購買商品、評價反饋、查看訂單這一整個流程都重新寫了一套出來。現在在“我的淘寶”裏面查看交易記錄的時候，還能發現“已買到的寶貝”裏面把機票和彩票另外列出來了，他們沒有加入到普通的訂單裏面去。在當時如果已經把會員、交易、商品、評價這些模塊拆分出來，就不用什麼都重做一遍了。
到2008年初，整個主站系統（有了機票、彩票系統之後，把原來的系統叫做主站）的容量已經到了瓶頸，商品數在一億以上，PV在2.5億以上，會員數超過了五千萬。這個時候Oracle的連接池數量都不夠用了，數據庫的容量到了極限，上層系統再增加機器也無法繼續擴容了，我們只有把底層的基礎服務繼續拆分，從底層開始擴容，上層才能擴展，這才能容納以後三五年的增長。
於是那一年我們專門啓動了一個更大的項目，把交易這個核心業務模塊也拆分出來了。原來的淘寶交易除了跟商品管理耦合在一起，也在支付寶和淘寶之間跳來跳去，跟支付寶耦合在一起，系統複雜，用戶體驗也很不好。我們把交易的底層業務拆出來叫交易中心TC（trade center），所謂底層業務是例如創建訂單、減庫存、修改訂單狀態等原子型的操作；交易的上層業務叫交易管理TM（trade manager），例如拍下一件普通商品要對訂單、庫存、物流進行操作，拍下虛擬商品不需要對物流進行操作，這些在TM裏面完成。這個項目取了一個很沒有創意的名字——“千島湖”，這幫開發人員取這個名字的目的是想在開發完畢之後，去千島湖玩一圈，後來他們如願以償了。這個時候還有一個項目也在搞，就是淘寶商城，之前拆分出來的那些基礎服務，給商城的快速構建，提供了良好的基礎。
類目屬性、用戶中心、交易中心，隨着這些模塊逐步的拆分和服務化改造，我們在系統架構方面也積累了不少的經驗。到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框架。再者，還有一個軟件工程方面的問題，這麼多層的一套系統，怎麼去測試它？