在系統(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包。另外在做淘寶機票、彩票系統(tǒng)的時候，頁面端也有很多東西需要復(fù)用，最直觀的是頁頭和頁腳，一開始我們每個系統(tǒng)里面復(fù)制了一份過去，但奇妙的是，那段時間頁腳要經(jīng)常修改，例如把“雅虎中國”改成“中國雅虎”，過一段時間又加了一個“口碑網(wǎng)”，再過一段時間變成了“雅虎口碑”，最后又變成了“中國雅虎”，每個系統(tǒng)都改一遍，折騰啊。后來我就把這部分velocity模版單獨拿出來了，做成了公用的模塊。

上面這些都是比較小的復(fù)用模塊，到2006年我們做了一個商品類目屬性的改造，在類目里面引入屬性的概念。項目的代號叫做“泰山”，如同它的名字，這是一個舉足輕重的項目，這個改變是一個劃時代的創(chuàng)新。在這之前的三年時間內(nèi)，商品的分類都是按照樹狀的一級一級的節(jié)點來分的，隨著商品數(shù)量的增長，類目也變得越來越深，越來越復(fù)雜，這帶給買家的就是查找一件商品要逐級類目點開，找商品之前要懂商品的分類。而淘寶運營部門管理類目的小二也發(fā)現(xiàn)一個很嚴(yán)重的問題——例如男裝里面有T恤、T恤下面有耐克、耐克有純棉的，女裝里面也有T恤、T恤下面還是有耐克、耐克下面依然有純棉的，那是先分男女裝再分款式再分品牌再分材質(zhì)呢？還是先分品牌再分款式再分材質(zhì)再分男女呢？暈倒了。這時候，一位大俠出來了——一燈，他說品牌、款式、材質(zhì)這種東東可以叫做“屬性”，屬性是類似tag的一個概念，與類目相比更加離散，更加靈活，這樣也縮減了類目的深度。這個思想的提出，一舉解決了分類的難題！從系統(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ù)，那個時候，很多商品屬性信息的后邊標(biāo)注著：“來自中關(guān)村在線”。有了類目屬性，給運營的工作帶來很大的便利，我們知道淘寶的運營主要就是類目的運營，什么季節(jié)推什么商品，都要在類目屬性上面做調(diào)整，讓買家更容易找到。例如夏天我要用戶在女裝一級類目下就標(biāo)出來材質(zhì)是不是蕾絲的、是不是純棉的，冬天卻要把羽絨衣調(diào)到女裝一級類目下，流行什么就要把什么商品往更高級的類目調(diào)整。這樣類目和屬性要經(jīng)常調(diào)整，隨之而來的問題就顯現(xiàn)了——調(diào)整到哪個類目，那類商品的賣家就要編輯一次自己的商品，隨著商品量的增長，賣家的工作量越來越大，然后我們就發(fā)現(xiàn)賣家受不了啦。到了2008年，我們研究了超市里面前后臺商品的分類，發(fā)現(xiàn)超市前臺商品可以隨季節(jié)和關(guān)聯(lián)來調(diào)整擺放場景（例如著名的啤酒和尿布的關(guān)聯(lián)），后臺倉庫里面要按照自然類目來存儲，二者密切關(guān)聯(lián)卻又相互分開。然后我們就把前后臺類目分開了，這樣賣家發(fā)布商品選擇的是自然類目和屬性，淘寶前臺展示的是根據(jù)運營需要而擺放的商品的類目和屬性。改造后的類目屬性服務(wù)取名叫做forest（森林，跟類目屬性有點神似。catserver還在，提供賣家授權(quán)、品牌服務(wù)、關(guān)鍵詞等相關(guān)的服務(wù)）。類目屬性的服務(wù)化，是淘寶在系統(tǒng)服務(wù)化方面做的第一個探索。

雖然個別架構(gòu)師具備了代碼潔癖，但淘寶前臺系統(tǒng)的業(yè)務(wù)量和代碼量還是爆炸式的增長了起來。業(yè)務(wù)方總在后面催，開發(fā)人員不夠了就繼續(xù)招人，招來的人根本看不懂原來的業(yè)務(wù)，只好摸索著在“合適的地方”加一些“合適的代碼”，看看運行起來像那么回事，就發(fā)布上線了。在這樣的惡性循環(huán)中，系統(tǒng)越來越臃腫，業(yè)務(wù)的耦合性越來越高，開發(fā)的效率越來越低。借用當(dāng)時比較流行的一句話“寫一段代碼，編譯一下能通過，半個小時就過去了；編譯一下沒通過，半天就過去了。”在這種情況下，系統(tǒng)出錯的概率也逐步增長，常常是你改了商品相關(guān)的某些代碼，發(fā)現(xiàn)交易出問題了，甚至你改了論壇上的某些代碼，旺旺出問題了。這讓開發(fā)人員苦不堪言，而業(yè)務(wù)方還認為這幫人干活越來越慢了。

大概是在2007年底的時候，研發(fā)部空降了一位從硅谷來的高管，空聞大師�？章勈且晃粶睾竦拈L者，他告訴我們一切要以穩(wěn)定為中心，所有影響系統(tǒng)穩(wěn)定的因素都要解決掉。例如每做一個日常修改，都必須整個系統(tǒng)回歸測試一遍；多個日常修改如果放在一個版本里面，要是一個功能沒有測試通過，整個系統(tǒng)都不能發(fā)布。我們把這個叫做“火車模型”，任何一個乘客沒有上車，都不許發(fā)車。這樣做的最直接后果就是火車一直晚點，新功能上線更慢了，我們能明顯的感覺到業(yè)務(wù)方的不滿，空聞的壓力肯定非常大。當(dāng)時我都不理解這種一刀切的做法，為了穩(wěn)定犧牲了發(fā)展的速度，這跟某Party的“穩(wěn)定壓倒一切”有什么分別？

但是到現(xiàn)在回過頭來看看，其實我們并沒有理解背后的思路。正是在這種要求下，我們不得不開始改變一些東西，例如把回歸測試日常化，每天晚上都跑一遍整個系統(tǒng)的回歸。還有就是在這種要求下，我們不得不對這個超級復(fù)雜的系統(tǒng)做肢解和重構(gòu)，其中復(fù)用性最高的一個模塊——用戶信息模塊開始拆分出來了，我們叫它UIC（user information center）。在UIC里面，它只處理最基礎(chǔ)的用戶信息操作，例如getUserById、getUserByName等等。

標(biāo)簽： 分布式 系統(tǒng)架構(gòu) 職場回顧 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。