作者陳金洲發(fā)布于2011年7月5日
新技術(shù)層出不窮。過去十年時(shí)間里，我們經(jīng)歷了許多激動(dòng)人心的新技術(shù)，包括那些新的框架、語(yǔ)言、平臺(tái)、編程模型等等。這些新技術(shù)極大地改善了開發(fā)人員的工作環(huán)境，縮短了產(chǎn)品和項(xiàng)目的面世時(shí)間。然而作為在軟件行業(yè)第一線工作多年的從業(yè)者，我們卻不得不面對(duì)一個(gè)現(xiàn)實(shí)，那就是當(dāng)初采用新技術(shù)的樂趣隨著項(xiàng)目周期的增長(zhǎng)而迅速減少。無論當(dāng)初的選擇多么光鮮，半年、一年之后，只要這個(gè)項(xiàng)目依然活躍，業(yè)務(wù)在擴(kuò)張——越來越多的功能需要加入，一些公共的問題就會(huì)逐漸顯露出來。構(gòu)建過慢，完成新功能讓你痛不欲生，團(tuán)隊(duì)成員無法很快融入，文檔無法及時(shí)更新等等。
在長(zhǎng)期運(yùn)轉(zhuǎn)的項(xiàng)目中，架構(gòu)的腐化是怎么產(chǎn)生的？為什么常見的面向?qū)ο蠹夹g(shù)無法解決這類問題？如何延緩架構(gòu)的腐化？
本文將嘗試解釋這一切，并提出相應(yīng)的解決方案。讀者需要具備相當(dāng)?shù)拈_發(fā)經(jīng)驗(yàn)——至少在同一個(gè)項(xiàng)目的開發(fā)上一年以上；公司負(fù)責(zé)架構(gòu)演進(jìn)、產(chǎn)品演進(jìn)的角色會(huì)從本文找到靈感。
架構(gòu)這個(gè)詞在各種場(chǎng)合不斷地以各種面目表現(xiàn)出來。從維基百科的詞條看來，我們經(jīng)常聽到的有插件架構(gòu)（Plugin），以數(shù)據(jù)庫(kù)為中心的架構(gòu)（DatabaseCentric），模型-視圖-控制器架構(gòu)（MVC），面向服務(wù)的架構(gòu)（SOA），三層模型(Three-Tiermodel)，模型驅(qū)動(dòng)架構(gòu)（MDA）等等等等。奇妙的是，這些詞越大，實(shí)際的開發(fā)者就越痛苦。SOA很好——但在它提出的那個(gè)年代，帶給開發(fā)者的只是面向廠商虛無縹緲的“公共數(shù)據(jù)類型”；MDA甚至都沒有機(jī)會(huì)淪為新一輪令人笑話的CASE工具。
在繼續(xù)閱讀之前，讀者不妨問自己一個(gè)問題：在長(zhǎng)期的項(xiàng)目中，這些大詞是否真的切實(shí)給你帶來過好處？更為功利的問題是：你，作為戰(zhàn)斗在一線的開發(fā)者，在長(zhǎng)期項(xiàng)目中可曾有過美好的體驗(yàn)？
企業(yè)應(yīng)用的發(fā)展似乎從十年前開始騰飛。從MicrosoftASP/LAMP(Linux、Apache、MySQL、PHP)年代開始，各種企業(yè)應(yīng)用紛紛向?yàn)g覽器遷移。經(jīng)過十年的發(fā)展，目前陣營(yíng)已經(jīng)百花齊放。與過去不同，現(xiàn)在的技術(shù)不僅僅在編程語(yǔ)言方面，常見的編程套路、最佳實(shí)踐、方法學(xué)、社區(qū)，都是各種技術(shù)獨(dú)特?fù)碛械?。目前占?jù)主流的陣營(yíng)有：
沒有理由對(duì)這些新技術(shù)不感到振奮。它們解決了許多它們出現(xiàn)之前的問題。在它們的網(wǎng)站上都宣稱各種生產(chǎn)效率如何之高的廣告語(yǔ)，類似于15分鐘創(chuàng)建一個(gè)博客應(yīng)用；2分鐘快速教程等等。比起過去21天才能學(xué)會(huì)XXX，現(xiàn)在它們?cè)谏鲜蛛y度上早已大幅度降低。
需要潑冷水的是，本文開篇提出的問題，在上述任何一種技術(shù)下，都如幽靈般揮之不去。采用Ruby onRails的某高效團(tuán)隊(duì)在10人團(tuán)隊(duì)工作半年之后，構(gòu)建時(shí)間從當(dāng)初的2分鐘變成2小時(shí)；我們之前采用Microsoft .NET 3.5 (C#3.0)的一個(gè)項(xiàng)目，在產(chǎn)生2萬行代碼的時(shí)候，構(gòu)建時(shí)間已經(jīng)超過半小時(shí)；我們的一些客戶，工作在10年的Java代碼庫(kù)上——他們竭盡全力，保持技術(shù)棧與時(shí)俱進(jìn)：Spring、Hibernate、Struts等，面對(duì)的困境是他們需要同時(shí)打開72個(gè)項(xiàng)目才能在Eclipse中獲得編譯；由于編譯打包時(shí)間過長(zhǎng)，他們?nèi)サ袅舜蟛糠值膯卧獪y(cè)試——帶來巨大的質(zhì)量風(fēng)險(xiǎn)。
如果你真的在一個(gè)長(zhǎng)期的項(xiàng)目工作過，你應(yīng)該清楚地了解到，這種痛苦，似乎不是任何一種框架能夠根本性解決的。這些新時(shí)代的框架解決了大部分顯而易見的問題，然而在一個(gè)長(zhǎng)期項(xiàng)目中所面對(duì)的問題，它們無能為力。
無論架構(gòu)師在任何時(shí)代以何種絢麗的方式描述架構(gòu)，開發(fā)中的項(xiàng)目不會(huì)超出下圖所示：
基本架構(gòu)示意
一些基本的準(zhǔn)則：
滿足這個(gè)條件的架構(gòu)在初期是非常令人愉悅的。上一部分我們描述的框架都符合這種架構(gòu)。這個(gè)階段開發(fā)非常快：IDE打開很快，開發(fā)功能完成很快，團(tuán)隊(duì)這個(gè)時(shí)候往往規(guī)模較小，交流也沒有問題。所有人都很高興——因?yàn)橛昧诵录夹g(shù)，因?yàn)檫@個(gè)架構(gòu)是如此的簡(jiǎn)單、清晰、有效。
好日子不算太長(zhǎng)。
很快你的老板（或者客戶，隨便什么）有一攬子的想法要在這個(gè)團(tuán)隊(duì)實(shí)現(xiàn)。工作有條不紊的展開。更多的功能加入進(jìn)來，更多的團(tuán)隊(duì)成員也加入了進(jìn)來。新加入的功能也按照之前的架構(gòu)方式開發(fā)著；新加入的團(tuán)隊(duì)成員也對(duì)清晰的架構(gòu)表示欣喜，也一絲不茍的遵循著。用不了多久——也許是三個(gè)月，或者更短，你會(huì)發(fā)現(xiàn)代碼庫(kù)變成下面的樣子：
正常開發(fā)之后
你也許很快會(huì)意識(shí)到這其中有什么問題。但你很難意識(shí)到這到底意味著什么。常見的動(dòng)作往往圍繞著重構(gòu)——將縱向相關(guān)的抽取出來，形成一個(gè)新的項(xiàng)目；橫向相關(guān)的抽取出來，形成一個(gè)名叫common或者base的項(xiàng)目。
無論你做什么類型的重構(gòu)，一些變化在悄悄產(chǎn)生（也許只是快慢的不同）。構(gòu)建過程不可避免的變長(zhǎng)。從剛開始的一兩分鐘變成好幾分鐘，到十幾分鐘。通過重構(gòu)構(gòu)建腳本，去掉那些不需要的部分，構(gòu)建時(shí)間會(huì)降到幾分鐘，你滿意了，于是繼續(xù)。
更多的功能、更多的成員加入了。構(gòu)建時(shí)間又變長(zhǎng)了。隨著加載代碼的增多，IDE也慢了下來；交流也多了起來——不是所有人能夠了解所有代碼了。在某些時(shí)候，一個(gè)很有道德的程序員嘗試重構(gòu)一部分重復(fù)邏輯，發(fā)現(xiàn)牽涉的代碼太多了，好多都是他看不懂的業(yè)務(wù)，于是他放棄了。更多的人這么做了，代碼庫(kù)越來越臃腫，最終沒有一個(gè)人能夠搞清楚系統(tǒng)具體是怎么工作的了。
系統(tǒng)在混亂的狀態(tài)下繼續(xù)緩慢地混亂——這個(gè)過程遠(yuǎn)比本文寫作的時(shí)間要長(zhǎng)很多，之間會(huì)有反復(fù)，但據(jù)我觀察，在不超過1年的時(shí)間內(nèi)，無論采用何種技術(shù)框架，應(yīng)用何種架構(gòu)，這個(gè)過程似乎是不可抗拒的宿命。
我們并非是坐以待斃的。身邊優(yōu)秀的同事們?cè)趩栴}發(fā)現(xiàn)之前采取了各種解決方案。常見的解決方案如下：
沒有什么比一臺(tái)與時(shí)俱進(jìn)的電腦更能激勵(lì)開發(fā)人員了。最多每隔三年，升級(jí)一次開發(fā)人員的電腦——升級(jí)到當(dāng)時(shí)最好的配置，能夠大幅度的提升生產(chǎn)效率，激勵(lì)開發(fā)人員。反過來，利用過時(shí)的電腦，在慢速的機(jī)器上進(jìn)行開發(fā)，帶來的不僅僅是客觀上開發(fā)效率的降低，更大程度上帶來的是開發(fā)人員心理上的懈怠。
升級(jí)的工作環(huán)境不僅僅是電腦，還包括工作的空間。良好的，促進(jìn)溝通的空間（以及工作方式）能夠促進(jìn)問題的發(fā)現(xiàn)從而減少問題的產(chǎn)生。隔斷不適合開發(fā)。
一般而言，構(gòu)建的順序是：本地構(gòu)建確保所有的功能運(yùn)行正常，然后提交等待持續(xù)集成工作正常。本地構(gòu)建超過5分鐘的時(shí)候就變得難以忍受；大多數(shù)情況下你希望這個(gè)反饋時(shí)間越短越好。項(xiàng)目的初期往往會(huì)運(yùn)行所有的步驟：編譯所有代碼，運(yùn)行所有測(cè)試。隨著項(xiàng)目周期的變長(zhǎng)，代碼的增多，時(shí)間會(huì)越來越長(zhǎng)。在嘗試若干次重構(gòu)構(gòu)建腳本再也沒辦法優(yōu)化之后，“分階段構(gòu)建”成為絕大多數(shù)的選擇。通過合理的拆分、分層，每次運(yùn)行特定的步驟，例如只運(yùn)行特定的測(cè)試、只構(gòu)建必要的部分；然后提交，讓持續(xù)集成服務(wù)器運(yùn)行所有的步驟。這樣開發(fā)者能夠繼續(xù)進(jìn)行后續(xù)的工作。
即便本地快了起來，采用分階段構(gòu)建的團(tuán)隊(duì)很快發(fā)現(xiàn)，CI服務(wù)器的構(gòu)建時(shí)間也越來越讓人不滿意。每次提交半小時(shí)之后才能得到構(gòu)建結(jié)果太不可接受了。各種各樣的分布式技術(shù)被創(chuàng)建出來。除了常見的CI服務(wù)器本身提供的能力，許多團(tuán)隊(duì)也發(fā)明了自己的分布式技術(shù)，他們往往能夠?qū)⒋a分布到多臺(tái)機(jī)器進(jìn)行編譯和運(yùn)行測(cè)試。這種解決方案能夠在比較長(zhǎng)的一段時(shí)間內(nèi)生效——當(dāng)構(gòu)建變慢的時(shí)候，只需要調(diào)整分布策略，讓構(gòu)建過程運(yùn)行在更多的集群機(jī)器上，就可以顯著的減少構(gòu)建時(shí)間。
一些新的工具能夠顯著地提速開發(fā)人員的工作。JRebel能夠?qū)⑿枰幾g的Java語(yǔ)言變成修改、保存立即生效，減少了大量的修改、保存、重新編譯、部署的時(shí)間；Spork能夠啟動(dòng)一個(gè)Server，將RSpec測(cè)試相關(guān)的代碼緩存于其中，這樣在運(yùn)行RSpec測(cè)試的時(shí)候就不用重新進(jìn)行加載，極大提升了效率。
上述的解決方案在特定的時(shí)間域內(nèi)很好地解決了一部分問題。然而，在項(xiàng)目運(yùn)轉(zhuǎn)一年，兩年或者更久，它們最終依然無法避免構(gòu)建時(shí)間變長(zhǎng)、開發(fā)變慢、代碼變得混亂、架構(gòu)晦澀難懂、新人難以上手等問題。到底問題的癥結(jié)是什么？
人們喜歡簡(jiǎn)潔。但這更多的看起來是一個(gè)謊言——沒有多少團(tuán)隊(duì)能夠自始至終保持簡(jiǎn)潔。人們喜歡簡(jiǎn)潔只是因?yàn)檫@個(gè)難以做到。并不是說人們不愿意如此。很多人都知道軟件開發(fā)不比其他的勞動(dòng)力密集型的行業(yè)——人越多，產(chǎn)量越大。《人月神話》中已經(jīng)提到，項(xiàng)目增加更多的人，在提升工作產(chǎn)出的同時(shí)，也產(chǎn)生了混亂。短期內(nèi)，這些混亂能夠被團(tuán)隊(duì)通過各種形式消化；但從長(zhǎng)期看來，隨著團(tuán)隊(duì)人員的變動(dòng)（新人加入，老人離開），以及人正常自然的遺忘曲線，代碼庫(kù)會(huì)逐漸失控，混亂無法被消化，而項(xiàng)目并不會(huì)停止，新功能不斷的加入，架構(gòu)就在一天天的過程中被腐蝕。
人的理解總有一個(gè)邊界，而需求和功能不會(huì)——今天的功能總比昨天的多；這個(gè)版本的功能總比上個(gè)版本的多。而在長(zhǎng)時(shí)間的開發(fā)中，忘記之前的代碼是正常的；忘記某些約定也是正常的。形成某些小而不經(jīng)意的錯(cuò)誤是正常的，在巨大的代碼庫(kù)中，這些小錯(cuò)誤被忽視也是正常的。這些不斷積攢的小小的不一致、錯(cuò)誤，隨著時(shí)間的積累，最終變得難以控制。
很少有人注意到，規(guī)模的變大才是導(dǎo)致架構(gòu)腐化的根源——因果關(guān)系在時(shí)空上的不連續(xù)，使得人們并不能從其中獲得經(jīng)驗(yàn)，只是一再重復(fù)這個(gè)悲劇的循環(huán)。
解決方案的終極目標(biāo)是：在混亂發(fā)生之前，在我們的認(rèn)知出現(xiàn)障礙之前，就將項(xiàng)目的規(guī)?？刂圃谝欢ǚ秶畠?nèi)。這并不容易。大多數(shù)團(tuán)隊(duì)都有相當(dāng)?shù)慕桓秹毫?。大多?shù)的業(yè)務(wù)用戶并沒有意識(shí)到，往一個(gè)項(xiàng)目/產(chǎn)品毫無節(jié)制地增加需求只會(huì)導(dǎo)致產(chǎn)品的崩潰。看看LotusNotes，你就知道產(chǎn)品最終會(huì)多么令人費(fèi)解、難以使用。我們這里主要討論的是技術(shù)方案。業(yè)務(wù)上你也需要始終對(duì)需求的增長(zhǎng)保持警惕。
這可能是最廉價(jià)的、最容易采用的方案。新技術(shù)的產(chǎn)生往往為了解決某些特定的問題，它們往往是經(jīng)驗(yàn)的集合。學(xué)習(xí)，理解這些新技術(shù)能夠極大程度減少過去為了完成某些技術(shù)目標(biāo)而進(jìn)行的必要的經(jīng)驗(yàn)積累過程。就像武俠小說中經(jīng)常有離奇遭遇的主人公突然獲得某個(gè)世外高人多年的內(nèi)力一樣，這些新技術(shù)能夠迅速幫助團(tuán)隊(duì)從某些特定的痛點(diǎn)中解脫出來。
已經(jīng)有足夠多的例子來證明這一觀點(diǎn)。在Spring出現(xiàn)之前，開發(fā)者的基本上只能遵循J2EE模式文檔中的各種實(shí)踐，來構(gòu)建自己的系統(tǒng)。有一些簡(jiǎn)單的框架能夠幫助這一過程，但總體來說，在處理今天看起來很基礎(chǔ)的如數(shù)據(jù)庫(kù)連接，異常管理，系統(tǒng)分層等等方面，還有很多手工的工作要做。Spring出現(xiàn)之后，你不需要花費(fèi)很多精力，很快就能得到一個(gè)系統(tǒng)分層良好、大部分設(shè)施已經(jīng)準(zhǔn)備就緒的基礎(chǔ)。這為減少代碼庫(kù)容量以及解決可能出現(xiàn)的低級(jí)Bug提供了幫助。
Rails則是另外一個(gè)極端的例子。Rails帶來的不僅僅是開發(fā)的便利，還帶來了人們?cè)贚inux世界多年的部署經(jīng)驗(yàn)。數(shù)據(jù)庫(kù)Migration， Apache +FastCGI或者nginx+passenger，這些過去看起來復(fù)雜異常的技術(shù)在Rails中變得無足輕重——稍懂命令行的人即可進(jìn)行部署。
任何一個(gè)組織都無法全部擁有這些新技術(shù)。因此作為軟件從業(yè)者，需要不斷地保持對(duì)技術(shù)社區(qū)的關(guān)注。閉門造車只能加速架構(gòu)的腐化——特別是這些自己的發(fā)明在開源社區(qū)早已有成熟的方案的時(shí)候。在那些貌似光鮮的產(chǎn)品背后，實(shí)際上有著無數(shù)的失敗的案例成功的經(jīng)驗(yàn)在支撐。
我們?cè)?jīng)有一個(gè)項(xiàng)目。在意識(shí)到需求可能轉(zhuǎn)向類似于key-value的文檔數(shù)據(jù)庫(kù)之后，團(tuán)隊(duì)大膽的嘗試采用SQLServer2008的XML能力，在SQLServer內(nèi)部實(shí)現(xiàn)了類似于No-SQL的數(shù)據(jù)庫(kù)。這是一個(gè)新的發(fā)明，創(chuàng)造者初期很興奮，終于有機(jī)會(huì)做不同的事情了。然而隨著項(xiàng)目的進(jìn)行，越來越多的需求出現(xiàn)了：Migration的支持、監(jiān)控、管理工具的支持、文檔、性能等等。隨著項(xiàng)目的進(jìn)展，最終發(fā)現(xiàn)這些能力與時(shí)下流行的MongoDB是如此的相似——MongoDB已經(jīng)解決了大多數(shù)的問題。這個(gè)時(shí)候，代碼庫(kù)已經(jīng)有相當(dāng)?shù)囊?guī)模了——而這部分的代碼，讓許多團(tuán)隊(duì)成員費(fèi)解；在一年之后，大約只有2個(gè)人能夠了解其實(shí)現(xiàn)過程。如果在早期采用MongoDB，團(tuán)隊(duì)本有機(jī)會(huì)摒棄大部分相關(guān)的工作。
值得一提的是，高傲的開發(fā)者往往對(duì)新技術(shù)不夠耐心；或者說對(duì)新技術(shù)的能力或局限缺乏足夠耐心去了解。每一個(gè)產(chǎn)品都有其針對(duì)的問題域，對(duì)于問題域之外，新技術(shù)往往沒有成熟到能夠應(yīng)對(duì)的地步。開發(fā)者需要不斷地閱讀、思考、參與，來驗(yàn)證自己的問題域是否與其匹配。淺嘗輒止不是好的態(tài)度，也阻礙了新技術(shù)在團(tuán)隊(duì)內(nèi)的推廣。
新技術(shù)的選型往往發(fā)生在項(xiàng)目/產(chǎn)品特定的時(shí)期，如開始階段，某個(gè)特定的痛點(diǎn)時(shí)期。日常階段，開發(fā)者仍然需要保持對(duì)代碼庫(kù)的關(guān)注。下一條，重構(gòu)到物理隔離的組件則是對(duì)不斷增大的代碼庫(kù)另一種解決方案。
顯而易見的趨勢(shì)是，對(duì)于同一個(gè)產(chǎn)品而言，需求總是不斷增多的。去年有100個(gè)功能，今年就有200個(gè)。去年有10萬行代碼，今年也許就有20萬行。去年2G內(nèi)存的機(jī)器能夠正常開發(fā)，今年似乎得加倍才行。去年有15個(gè)開發(fā)人員，今年就到30個(gè)了。去年構(gòu)建一次最多15–20分鐘，今年就得1個(gè)小時(shí)了，還得整個(gè)分布式的。
有人會(huì)注意到代碼的設(shè)計(jì)問題，孜孜不倦地進(jìn)行著重構(gòu)；有人會(huì)注意到構(gòu)建變慢的問題，不懈地改進(jìn)著構(gòu)建時(shí)間。然而很少有人注意到代碼庫(kù)的變大才是問題的根源。很多常規(guī)的策略往往是針對(duì)組織的：例如將代碼庫(kù)按照功能模塊劃分（例如ABC功能之類）或者按層次劃分（例如持久層、表現(xiàn)層），但這些拆分之后的項(xiàng)目依然存在于開發(fā)人員的工作空間中。無論項(xiàng)目如何組織，開發(fā)者都需要打開所有的項(xiàng)目才能完成編譯和運(yùn)行過程。我曾經(jīng)見到一個(gè)團(tuán)隊(duì)需要在VisualStudio中打開120個(gè)項(xiàng)目；我自己也經(jīng)歷過需要在Eclipse中打開72個(gè)項(xiàng)目才能完成編譯。
解決方案是物理隔離這些組件。就像團(tuán)隊(duì)在使用Spring/Hibernate/Asp.NETMVC/ActiveRecord這些庫(kù)的時(shí)候，不用將它們對(duì)應(yīng)的源代碼放到工作空間進(jìn)行編譯一樣，團(tuán)隊(duì)也可以將穩(wěn)定工作的代碼單元整理出來形成對(duì)應(yīng)的庫(kù)，標(biāo)記版本然后直接引用二進(jìn)制文件。
在不同的技術(shù)平臺(tái)上有著不同的方案。Java世界有歷史悠久的Maven庫(kù)，能夠良好的將不同版本的JAR以及他們的以來進(jìn)行管理；.NET比較遺憾，這方面真正成熟的什么也沒有——但參考Maven的實(shí)現(xiàn)，團(tuán)隊(duì)自己造一個(gè)也不是難事（可能比較困難的是與MSBuild的集成）；Ruby/Rails世界則有著名的gem/bundler系統(tǒng)。將自己整理出來的比較獨(dú)立的模塊不要放到rails/lib/中，整理出來，形成一個(gè)新的gem，對(duì)其進(jìn)行依賴引用（團(tuán)隊(duì)內(nèi)需要搭建自己的gems庫(kù)）。
同時(shí)，代碼庫(kù)也需要進(jìn)行大刀闊斧的整改。之前的代碼結(jié)構(gòu)可能如下，（這里以SVN為例，因?yàn)镾VN有明確的trunk/branches/tags目錄結(jié)構(gòu)。git/hg類似）
原來的庫(kù)結(jié)構(gòu)
改進(jìn)之后，將會(huì)如下圖所示：
改進(jìn)的庫(kù)結(jié)構(gòu)
每個(gè)模塊都有屬于自己的代碼庫(kù)，擁有自己的獨(dú)立的升級(jí)和發(fā)布周期，甚至有自己的文檔。
這一方案看起來很容易理解，但在實(shí)際操作過程中則困難重重。團(tuán)隊(duì)運(yùn)轉(zhuǎn)很長(zhǎng)一段時(shí)間之后，很少有人去關(guān)心模塊之間的依賴。一旦要拆分出來，去分析幾十上百個(gè)現(xiàn)存項(xiàng)目之間的依賴相當(dāng)費(fèi)勁。最簡(jiǎn)單的處理辦法是，檢查代碼庫(kù)的提交記錄，例如最近3個(gè)月之內(nèi)某個(gè)模塊就沒有人提交過，那么這個(gè)模塊基本上就可以拿出來形成二進(jìn)制依賴了。
很多開源產(chǎn)品都是通過這個(gè)過程形成的，例如Spring（請(qǐng)參考閱讀《J2EE設(shè)計(jì)開發(fā)編程指南》，Rod Johnson基本上闡述了整個(gè)Spring的設(shè)計(jì)思路來源）。一旦團(tuán)隊(duì)開始這樣去思考，每隔一段時(shí)間重新審視代碼庫(kù)，你會(huì)發(fā)現(xiàn)核心代碼庫(kù)不可能失控，同時(shí)也獲得了一組設(shè)計(jì)良好、工作穩(wěn)定的組件。
上面的解決方案核心原則只有一條：始終將核心代碼庫(kù)控制在團(tuán)隊(duì)可以理解的范圍內(nèi)。如果運(yùn)轉(zhuǎn)良好，能夠很大程度上解決架構(gòu)因?yàn)榇a規(guī)模變大而腐化的問題。然而該解決方案只解決了在系統(tǒng)在靜態(tài)層面的隔離。當(dāng)隔離出的模塊越來越多，系統(tǒng)也因此也需要越來越多的依賴來運(yùn)行。這部分依賴在運(yùn)行期分為兩類：一類是類似于 Spring/Hibernate/ApacheCommons之類的，系統(tǒng)運(yùn)行的基礎(chǔ)，運(yùn)行期這些必須存在；另外一類是相對(duì)獨(dú)立的業(yè)務(wù)功能，例如緩存的讀取，電子商城的支付模塊等。
第二類依賴則可以更進(jìn)一步：將其放到獨(dú)立的進(jìn)程中。現(xiàn)在稍具規(guī)模的系統(tǒng)，登錄、注銷功能已經(jīng)從應(yīng)用中脫離而出，要么采用SSO的方案來進(jìn)行登陸，要么則干脆代理給別的登陸系統(tǒng)。LiveJournal團(tuán)隊(duì)在開發(fā)過程中，發(fā)現(xiàn)緩存的讀寫實(shí)際上可以放到獨(dú)立的進(jìn)程中進(jìn)行（而不是類似EhCache的方案，直接運(yùn)行于所在的運(yùn)行環(huán)境中），于是發(fā)明了現(xiàn)在鼎鼎有名的memcached.我們之前進(jìn)行的一個(gè)項(xiàng)目中，發(fā)現(xiàn)支付模塊完全能夠獨(dú)立出來，于是將其進(jìn)行隔離，形成了一個(gè)新的、沒有界面的、永遠(yuǎn)在運(yùn)行的系統(tǒng)，通過REST處理支付請(qǐng)求。在另外一個(gè)出版項(xiàng)目中，我們發(fā)現(xiàn)編輯編寫報(bào)告的過程實(shí)際上與報(bào)告發(fā)行過程雖然存在類級(jí)別的重用，但在業(yè)務(wù)層面是獨(dú)立的。最終我們將報(bào)告發(fā)行過程做成了一個(gè)常駐服務(wù)，系統(tǒng)其他的模塊通過MQ消息與其進(jìn)行交互。
這一解決方案應(yīng)該不難理解。與解決方案1不同的是，這一方案更多的是要對(duì)系統(tǒng)進(jìn)行面向業(yè)務(wù)層面的思考。由于系統(tǒng)將會(huì)以獨(dú)立的進(jìn)程來運(yùn)行這一模塊，在不同的進(jìn)程中可能存在一定的代碼重復(fù)。例如Spring同時(shí)存在兩個(gè)不相關(guān)的項(xiàng)目中大家覺得沒什么大不了的；但如果是自己的某個(gè)業(yè)務(wù)組件同時(shí)在同一個(gè)項(xiàng)目的兩個(gè)進(jìn)程中重復(fù)，許多人就有些潔癖不可接受了。（題外話：這種潔癖在OSGi環(huán)境中也存在）這里需要提醒的是：當(dāng)處于不同的進(jìn)程時(shí)，它們?cè)谖锢砩?、運(yùn)行時(shí)上已經(jīng)徹底隔離了。必須以進(jìn)程的觀點(diǎn)去思考整個(gè)架構(gòu)，而不是簡(jiǎn)單的物理結(jié)構(gòu)。
從單進(jìn)程模型到多進(jìn)程模型的架構(gòu)思維轉(zhuǎn)變也不太容易——需要架構(gòu)師有意識(shí)的加強(qiáng)這方面的練習(xí)。流行的.NET和Java世界傾向于把什么都放到一起。而Linux世界Rails/Django則能更好的平衡優(yōu)秀產(chǎn)品之間的進(jìn)程協(xié)調(diào)。例如memcached的使用。另外，現(xiàn)在多核環(huán)境越來越多，與其費(fèi)盡心思在編程語(yǔ)言層面上不如享受多核的好處，多進(jìn)程能夠簡(jiǎn)單并且顯著地利用多核能力。
現(xiàn)在將眼光看更遠(yuǎn)一些。想象一下我們?cè)谧鲆粋€(gè)類似于開心網(wǎng)、Facebook、人人網(wǎng)的系統(tǒng)。它們的共同特點(diǎn)是能夠接入幾乎無限的第三方應(yīng)用，無論是買賣朋友這類簡(jiǎn)單的應(yīng)用，還是絢麗無比的各種社交游戲。神奇的是，實(shí)現(xiàn)這一點(diǎn)并不需要第三方應(yīng)用的開發(fā)者采用跟它們一樣的技術(shù)平臺(tái)，也不需要服務(wù)端提供無限的運(yùn)算能力——大部分的架構(gòu)由開發(fā)方來控制。
在企業(yè)應(yīng)用中實(shí)現(xiàn)這個(gè)并不難。這其中的秘訣在于：當(dāng)用戶通過Facebook訪問某個(gè)第三方應(yīng)用的時(shí)候，F(xiàn)acebook實(shí)際上通過后臺(tái)去訪問了第三方應(yīng)用，將當(dāng)前用戶的信息（以及好友信息）通過HTTPPOST送到第三方應(yīng)用指定的服務(wù)網(wǎng)址，然后將應(yīng)用的HTML結(jié)果渲染到當(dāng)前頁(yè)面中。某種意義上說，這種技術(shù)本質(zhì)上是一種服務(wù)器端的mashup.（詳情參考InfoQ 文章）
Facebook App架構(gòu)
這種架構(gòu)的優(yōu)點(diǎn)在于極度的分布式。從外觀上看起來一致的系統(tǒng)，實(shí)際由若干個(gè)耦合極低、技術(shù)架構(gòu)完全不同的小應(yīng)用組成。它們不需要被部署在同一臺(tái)機(jī)器上，可以單獨(dú)地開發(fā)、升級(jí)、優(yōu)化。一個(gè)應(yīng)用的癱瘓不影響整個(gè)系統(tǒng)的運(yùn)行；每個(gè)應(yīng)用的自行升級(jí)對(duì)整個(gè)系統(tǒng)也完全沒有影響。
這并非是終極的解決方案，只在某些特定的條件下有效。當(dāng)系統(tǒng)規(guī)模上非常龐大，例如由若干個(gè)子系統(tǒng)組成；界面基本一致；子系統(tǒng)之間關(guān)聯(lián)較少。針對(duì)這個(gè)前提，可以考慮采用這種架構(gòu)。抽象出極少的、真正有效公用的信息，在系統(tǒng)之間通過HTTPPOST.。其他的系統(tǒng)完全可以獨(dú)立開發(fā)、部署，甚至針對(duì)應(yīng)用訪問的情況進(jìn)行特定的部署優(yōu)化。如果不這么做，動(dòng)輒上百萬千萬行的代碼堆在一個(gè)系統(tǒng)中，隨著時(shí)間的推移，開發(fā)者逐漸對(duì)代碼失控，架構(gòu)的腐化是遲早的事情。
例如，銀行的財(cái)務(wù)系統(tǒng)，包括了十多個(gè)個(gè)子系統(tǒng)，包括薪資、資產(chǎn)、報(bào)表等等模塊，每一部分功能都相對(duì)獨(dú)立并且復(fù)雜。整個(gè)系統(tǒng)如果按照這種方式拆分，就能夠?qū)崿F(xiàn)單點(diǎn)優(yōu)化而無需重新啟動(dòng)整個(gè)應(yīng)用。針對(duì)每個(gè)應(yīng)用，開發(fā)者能夠在更小的代碼內(nèi)采用自己熟悉的技術(shù)方案，從而減少架構(gòu)腐化的可能。
我訪問過很多團(tuán)隊(duì)。在很多項(xiàng)目開始的時(shí)候，他們花很多時(shí)間在選擇用何種技術(shù)體系，何種架構(gòu)，乃至何種IDE。就像小孩子選擇自己鐘愛的玩具，我相信無論過程如何，團(tuán)隊(duì)最終都會(huì)欣然選擇他們所選擇的，并且堅(jiān)信他們的選擇沒有錯(cuò)誤。事實(shí)也確實(shí)如此。在項(xiàng)目的開始階段很難有真正的架構(gòu)挑戰(zhàn)。困難的地方在于，隨著時(shí)間的增長(zhǎng)，人們會(huì)忘記；有很多的人加入，他們需要理解舊代碼的同時(shí)完成新功能；每一次代碼量的突破，都會(huì)引起架構(gòu)的不適應(yīng)；這些不適應(yīng)包括：新功能引入變得困難，新人難以迅速上手；構(gòu)建時(shí)間變長(zhǎng)等等。這些能否引起團(tuán)隊(duì)的警覺，并且采取結(jié)構(gòu)性的解決方案而不是臨時(shí)性的。
很多人說敏捷不提倡文檔。他們說文檔很難寫。他們說開發(fā)人員寫不了文檔。于是就沒有文檔。
奇怪的是我看到的情況卻不是這樣。程序?qū)懙脙?yōu)秀的人，寫起文字來也很不錯(cuò)。ThoughtBlogs上絕大多數(shù)都是程序員，很多人的文字寫得都很贊。
而項(xiàng)目中的文檔往往少得可憐。新人來了總是一頭霧水。令人奇怪的是，新人能夠一天或者兩天之內(nèi)通過閱讀RSpec或者JBehave迅速了解這些工具的使用，到了團(tuán)隊(duì)里面卻沒有了文檔。
拋開項(xiàng)目持續(xù)運(yùn)轉(zhuǎn)并交付的特性不談，我認(rèn)為巨大的、不穩(wěn)定的代碼庫(kù)是文檔迅速失效的根源。如果我們能夠按照上述的解決方案，將代碼庫(kù)縮小，那么獨(dú)立出來的模塊或者應(yīng)用就有機(jī)會(huì)在更小的范圍內(nèi)具備更獨(dú)特的價(jià)值。想象一下現(xiàn)在的Rails3/Spring框架，他們往往有超過20個(gè)第三方依賴，我們卻沒有覺得理解困難，最重要的原因是依賴隔離之后，這些模塊有了獨(dú)立的文檔可以學(xué)習(xí)。
企業(yè)級(jí)項(xiàng)目也可以如此。
功能總是不斷的、不斷的加到同一個(gè)產(chǎn)品中。這毫不奇怪。然而通過我們前面的分析，我們應(yīng)當(dāng)重新思考這個(gè)常識(shí)。是創(chuàng)建一個(gè)日益龐大的、緩慢的、毫無生機(jī)的產(chǎn)品，還是將其有機(jī)分解，成為一個(gè)生機(jī)勃勃的具有不同依賴的生態(tài)系統(tǒng)？項(xiàng)目的各方人員（包括業(yè)務(wù)用戶、架構(gòu)師、開發(fā)者）應(yīng)當(dāng)從短視的眼光中走出來，著眼于創(chuàng)建可持續(xù)的應(yīng)用程序生態(tài)系統(tǒng)。
關(guān)于作者
陳金洲，Buffalo Ajax Framework作者，ThoughtWorks中國(guó)公司首席咨詢師，現(xiàn)居西安。目前的工作主要集中在RichClient開發(fā)，同時(shí)一直對(duì)Web可用性進(jìn)行觀察，并對(duì)其實(shí)現(xiàn)保持興趣。
聯(lián)系客服
