前言

　　新技術(shù)層出不窮。過去十年時間里，我們經(jīng)歷了許多激動人心的新技術(shù)，包括那些新的框架、語言、平臺、編程模型等等。這些新技術(shù)極大地改善了開發(fā)人員的工作環(huán)境，縮短了產(chǎn)品和項目的面世時間。然而作為在軟件行業(yè)第一線工作多年的從業(yè)者，我們卻不得不面對一個現(xiàn)實，那就是當初采用新技術(shù)的樂趣隨著項目周期的增長而迅速減少。無論當初的選擇多么光鮮，半年、一年之后，只要這個項目依然活躍，業(yè)務在擴張 —— 越來越多的功能需要加入，一些公共的問題就會逐漸顯露出來。構(gòu)建過慢，完成新功能讓你痛不欲生，團隊成員無法很快融入，文檔無法及時更新等等。

　　在長期運轉(zhuǎn)的項目中，架構(gòu)的腐化是怎么產(chǎn)生的？為什么常見的面向?qū)ο蠹夹g(shù)無法解決這類問題？如何延緩架構(gòu)的腐化？

　　本文將嘗試解釋這一切，并提出相應的解決方案。讀者需要具備相當?shù)拈_發(fā)經(jīng)驗 —— 至少在同一個項目的開發(fā)上一年以上；公司負責架構(gòu)演進、產(chǎn)品演進的角色會從本文找到靈感。

　　架構(gòu)

　　架構(gòu)這個詞在各種場合不斷地以各種面目表現(xiàn)出來。從維基百科的詞條看來，我們經(jīng)常聽到的有插件架構(gòu)（Plugin），以數(shù)據(jù)庫為中心的架構(gòu)（Database Centric），模型-視圖-控制器架構(gòu)（MVC），面向服務的架構(gòu)（SOA），三層模型(Three-Tier model)，模型驅(qū)動架構(gòu)（MDA）等等等等。奇妙的是，這些詞越大，實際的開發(fā)者就越痛苦。SOA很好 —— 但在它提出的那個年代，帶給開發(fā)者的只是面向廠商虛無縹緲的“公共數(shù)據(jù)類型”；MDA甚至都沒有機會淪為新一輪令人笑話的CASE工具。

　　在繼續(xù)閱讀之前，讀者不妨問自己一個問題：在長期的項目中，這些大詞是否真的切實給你帶來過好處？更為功利的問題是：你，作為戰(zhàn)斗在一線的開發(fā)者，在長期項目中可曾有過美好的體驗？

　　技術(shù)的演變與揮之不去的痛

　　企業(yè)應用的發(fā)展似乎從十年前開始騰飛。從Microsoft ASP/LAMP(Linux、Apache、MySQL、php)年代開始，各種企業(yè)應用紛紛向瀏覽器遷移。經(jīng)過十年的發(fā)展，目前陣營已經(jīng)百花齊放。與過去不同，現(xiàn)在的技術(shù)不僅僅在編程語言方面，常見的編程套路、最佳實踐、方法學、社區(qū)，都是各種技術(shù)獨特擁有的。目前占據(jù)主流的陣營有：

• Rails
• Java EE平臺。值得一提的是Java VM已經(jīng)成為一種新的宿主平臺，Scala、JRuby更為活躍并引人矚目
• LAMP平臺。Linux/MySQL/Apache并沒有多少變化，php社區(qū)從Rails社區(qū)獲得了不少養(yǎng)分，出現(xiàn)了許多更加優(yōu)秀的開發(fā)框架
• Microsoft .NET平臺
• Django

　　沒有理由對這些新技術(shù)不感到振奮。它們解決了許多它們出現(xiàn)之前的問題。在它們的網(wǎng)站上都宣稱各種生產(chǎn)效率如何之高的廣告語，類似于15分鐘創(chuàng)建一個博客應用；2分鐘快速教程等等。比起過去21天才能學會XXX，現(xiàn)在它們在上手難度上早已大幅度降低。

　　需要潑冷水的是，本文開篇提出的問題，在上述任何一種技術(shù)下，都如幽靈般揮之不去。采用Ruby on Rails的某高效團隊在10人團隊工作半年之后，構(gòu)建時間從當初的2分鐘變成2小時；我們之前采用Microsoft .NET 3.5 (C# 3.0)的一個項目，在產(chǎn)生2萬行代碼的時候，構(gòu)建時間已經(jīng)超過半小時；我們的一些客戶，工作在10年的Java代碼庫上 —— 他們竭盡全力，保持技術(shù)棧與時俱進：Spring、Hibernate、Struts等，面對的困境是他們需要同時打開72個項目才能在Eclipse中獲得編譯；由于編譯打包時間過長，他們?nèi)サ袅舜蟛糠值膯卧獪y試 —— 帶來巨大的質(zhì)量風險。

　　如果你真的在一個長期的項目工作過，你應該清楚地了解到，這種痛苦，似乎不是任何一種框架能夠根本性解決的。這些新時代的框架解決了大部分顯而易見的問題，然而在一個長期項目中所面對的問題，它們無能為力。

　　一步一步：架構(gòu)是如何腐化的

　　無論架構(gòu)師在任何時代以何種絢麗的方式描述架構(gòu)，開發(fā)中的項目不會超出下圖所示：

　　基本架構(gòu)示意

　　一些基本的準則：

• 為了降低耦合，系統(tǒng)應當以恰當?shù)姆绞竭M行分層。目前最經(jīng)考驗的分層是MVC+Service。
• 為了提供基礎的訪問，一些基本的、平臺級別的API應該被引入。用Spring之類的框架來做這件事情。
• 用AOP進行橫向切分業(yè)務層面共性的操作，例如日志、權(quán)限等。
• 為了保證項目正常構(gòu)建，你還需要數(shù)據(jù)庫、持續(xù)集成服務器，以及對應的與環(huán)境無關的構(gòu)建腳本和數(shù)據(jù)庫遷移腳本。

　　階段1

　　滿足這個條件的架構(gòu)在初期是非常令人愉悅的。上一部分我們描述的框架都符合這種架構(gòu)。這個階段開發(fā)非常快：IDE打開很快，開發(fā)功能完成很快，團隊這個時候往往規(guī)模較小，交流也沒有問題。所有人都很高興 ——因為用了新技術(shù)，因為這個架構(gòu)是如此的簡單、清晰、有效。

　　階段2

　　好日子不算太長。

　　很快你的老板（或者客戶，隨便什么）有一攬子的想法要在這個團隊實現(xiàn)。工作有條不紊的展開。更多的功能加入進來，更多的團隊成員也加入了進來。新加入的功能也按照之前的架構(gòu)方式開發(fā)著；新加入的團隊成員也對清晰的架構(gòu)表示欣喜，也一絲不茍的遵循著。用不了多久 —— 也許是三個月，或者更短，你會發(fā)現(xiàn)代碼庫變成下面的樣子：

　　正常開發(fā)之后

　　你也許很快會意識到這其中有什么問題。但你很難意識到這到底意味著什么。常見的動作往往圍繞著重構(gòu) —— 將縱向相關的抽取出來，形成一個新的項目；橫向相關的抽取出來，形成一個名叫common或者base的項目。

　　無論你做什么類型的重構(gòu)，一些變化在悄悄產(chǎn)生（也許只是快慢的不同）。構(gòu)建過程不可避免的變長。從剛開始的一兩分鐘變成好幾分鐘，到十幾分鐘。通過重構(gòu)構(gòu)建腳本，去掉那些不需要的部分，構(gòu)建時間會降到幾分鐘，你滿意了，于是繼續(xù)。

　　階段3

　　更多的功能、更多的成員加入了。構(gòu)建時間又變長了。隨著加載代碼的增多，IDE也慢了下來；交流也多了起來 —— 不是所有人能夠了解所有代碼了。在某些時候，一個很有道德的程序員嘗試重構(gòu)一部分重復邏輯，發(fā)現(xiàn)牽涉的代碼太多了，好多都是他看不懂的業(yè)務，于是他放棄了。更多的人這么做了，代碼庫越來越臃腫，最終沒有一個人能夠搞清楚系統(tǒng)具體是怎么工作的了。

　　系統(tǒng)在混亂的狀態(tài)下繼續(xù)緩慢地混亂 —— 這個過程遠比本文寫作的時間要長很多，之間會有反復，但據(jù)我觀察，在不超過1年的時間內(nèi)，無論采用何種技術(shù)框架，應用何種架構(gòu)，這個過程似乎是不可抗拒的宿命。

　　常見的解決方案

　　我們并非是坐以待斃的。身邊優(yōu)秀的同事們在問題發(fā)現(xiàn)之前采取了各種解決方案。常見的解決方案如下：

　　升級工作環(huán)境

　　沒有什么比一臺與時俱進的電腦更能激勵開發(fā)人員了。最多每隔三年，升級一次開發(fā)人員的電腦 —— 升級到當時最好的配置，能夠大幅度的提升生產(chǎn)效率，激勵開發(fā)人員。反過來，利用過時的電腦，在慢速的機器上進行開發(fā)，帶來的不僅僅是客觀上開發(fā)效率的降低，更大程度上帶來的是開發(fā)人員心理上的懈怠。

　　升級的工作環(huán)境不僅僅是電腦，還包括工作的空間。良好的，促進溝通的空間（以及工作方式）能夠促進問題的發(fā)現(xiàn)從而減少問題的產(chǎn)生。隔斷不適合開發(fā)。

　　分階段的構(gòu)建

　　一般而言，構(gòu)建的順序是：本地構(gòu)建確保所有的功能運行正常，然后提交等待持續(xù)集成工作正常。本地構(gòu)建超過5分鐘的時候就變得難以忍受；大多數(shù)情況下你希望這個反饋時間越短越好。項目的初期往往會運行所有的步驟：編譯所有代碼，運行所有測試。隨著項目周期的變長，代碼的增多，時間會越來越長。在嘗試若干次重構(gòu)構(gòu)建腳本再也沒辦法優(yōu)化之后，“分階段構(gòu)建”成為絕大多數(shù)的選擇。通過合理的拆分、分層，每次運行特定的步驟，例如只運行特定的測試、只構(gòu)建必要的部分；然后提交，讓持續(xù)集成服務器運行所有的步驟。這樣開發(fā)者能夠繼續(xù)進行后續(xù)的工作。

　　分布式構(gòu)建

　　即便本地快了起來，采用分階段構(gòu)建的團隊很快發(fā)現(xiàn)，CI服務器的構(gòu)建時間也越來越讓人不滿意。每次提交半小時之后才能得到構(gòu)建結(jié)果太不可接受了。各種各樣的分布式技術(shù)被創(chuàng)建出來。除了常見的CI服務器本身提供的能力，許多團隊也發(fā)明了自己的分布式技術(shù)，他們往往能夠?qū)⒋a分布到多臺機器進行編譯和運行測試。這種解決方案能夠在比較長的一段時間內(nèi)生效 —— 當構(gòu)建變慢的時候，只需要調(diào)整分布策略，讓構(gòu)建過程運行在更多的集群機器上，就可以顯著的減少構(gòu)建時間。

　　采用JRebel或者Spork

　　一些新的工具能夠顯著地提速開發(fā)人員的工作。JRebel能夠?qū)⑿枰幾g的Java語言變成修改、保存立即生效，減少了大量的修改、保存、重新編譯、部署的時間；Spork能夠啟動一個Server，將RSpec測試相關的代碼緩存于其中，這樣在運行RSpec測試的時候就不用重新進行加載，極大提升了效率。

　　到底是什么問題？

　　上述的解決方案在特定的時間域內(nèi)很好地解決了一部分問題。然而，在項目運轉(zhuǎn)一年，兩年或者更久，它們最終依然無法避免構(gòu)建時間變長、開發(fā)變慢、代碼變得混亂、架構(gòu)晦澀難懂、新人難以上手等問題。到底問題的癥結(jié)是什么？

　　人們喜歡簡潔。但這更多的看起來是一個謊言 —— 沒有多少團隊能夠自始至終保持簡潔。人們喜歡簡潔只是因為這個難以做到。并不是說人們不愿意如此。很多人都知道軟件開發(fā)不比其他的勞動力密集型的行業(yè) —— 人越多，產(chǎn)量越大。《人月神話》中已經(jīng)提到，項目增加更多的人，在提升工作產(chǎn)出的同時，也產(chǎn)生了混亂。短期內(nèi)，這些混亂能夠被團隊通過各種形式消化；但從長期看來，隨著團隊人員的變動（新人加入，老人離開），以及人正常自然的遺忘曲線，代碼庫會逐漸失控，混亂無法被消化，而項目并不會停止，新功能不斷的加入，架構(gòu)就在一天天的過程中被腐蝕。

　　人的理解總有一個邊界，而需求和功能不會 —— 今天的功能總比昨天的多；這個版本的功能總比上個版本的多。而在長時間的開發(fā)中，忘記之前的代碼是正常的；忘記某些約定也是正常的。形成某些小而不經(jīng)意的錯誤是正常的，在巨大的代碼庫中，這些小錯誤被忽視也是正常的。這些不斷積攢的小小的不一致、錯誤，隨著時間的積累，最終變得難以控制。

　　很少有人注意到，規(guī)模的變大才是導致架構(gòu)腐化的根源 —— 因果關系在時空上的不連續(xù)，使得人們并不能從其中獲得經(jīng)驗，只是一再重復這個悲劇的循環(huán)。

　　解決方案

　　解決方案的終極目標是：在混亂發(fā)生之前，在我們的認知出現(xiàn)障礙之前，就將項目的規(guī)模控制在一定范圍之內(nèi)。這并不容易。大多數(shù)團隊都有相當?shù)慕桓秹毫Α４蠖鄶?shù)的業(yè)務用戶并沒有意識到，往一個項目/產(chǎn)品毫無節(jié)制地增加需求只會導致產(chǎn)品的崩潰。看看Lotus Notes，你就知道產(chǎn)品最終會多么令人費解、難以使用。我們這里主要討論的是技術(shù)方案。業(yè)務上你也需要始終對需求的增長保持警惕。

　　0. 采用新技術(shù)

　　這可能是最廉價的、最容易采用的方案。新技術(shù)的產(chǎn)生往往為了解決某些特定的問題，它們往往是經(jīng)驗的集合。學習，理解這些新技術(shù)能夠極大程度減少過去為了完成某些技術(shù)目標而進行的必要的經(jīng)驗積累過程。就像武俠小說中經(jīng)常有離奇遭遇的主人公突然獲得某個世外高人多年的內(nèi)力一樣，這些新技術(shù)能夠迅速幫助團隊從某些特定的痛點中解脫出來。

　　已經(jīng)有足夠多的例子來證明這一觀點。在Spring出現(xiàn)之前，開發(fā)者的基本上只能遵循J2EE模式文檔中的各種實踐，來構(gòu)建自己的系統(tǒng)。有一些簡單的框架能夠幫助這一過程，但總體來說，在處理今天看起來很基礎的如數(shù)據(jù)庫連接，異常管理，系統(tǒng)分層等等方面，還有很多手工的工作要做。Spring出現(xiàn)之后，你不需要花費很多精力，很快就能得到一個系統(tǒng)分層良好、大部分設施已經(jīng)準備就緒的基礎。這為減少代碼庫容量以及解決可能出現(xiàn)的低級Bug提供了幫助。

　　Rails則是另外一個極端的例子。Rails帶來的不僅僅是開發(fā)的便利，還帶來了人們在Linux世界多年的部署經(jīng)驗。數(shù)據(jù)庫Migration， Apache + FastCGI或者nginx + passenger，這些過去看起來復雜異常的技術(shù)在Rails中變得無足輕重 —— 稍懂命令行的人即可進行部署。

　　任何一個組織都無法全部擁有這些新技術(shù)。因此作為軟件從業(yè)者，需要不斷地保持對技術(shù)社區(qū)的關注。閉門造車只能加速架構(gòu)的腐化 —— 特別是這些自己的發(fā)明在開源社區(qū)早已有成熟的方案的時候。在那些貌似光鮮的產(chǎn)品背后，實際上有著無數(shù)的失敗的案例成功的經(jīng)驗在支撐。

　　我們曾經(jīng)有一個項目。在意識到需求可能轉(zhuǎn)向類似于key-value的文檔數(shù)據(jù)庫之后，團隊大膽的嘗試采用SQL Server  2008的XML能力，在SQL Server內(nèi)部實現(xiàn)了類似于No-SQL的數(shù)據(jù)庫。這是一個新的發(fā)明，創(chuàng)造者初期很興奮，終于有機會做不同的事情了。然而隨著項目的進行，越來越多的需求出現(xiàn)了：Migration的支持、監(jiān)控、管理工具的支持、文檔、性能等等。隨著項目的進展，最終發(fā)現(xiàn)這些能力與時下流行的MongoDB是如此的相似 —— MongoDB已經(jīng)解決了大多數(shù)的問題。這個時候，代碼庫已經(jīng)有相當?shù)囊?guī)模了 —— 而這部分的代碼，讓許多團隊成員費解；在一年之后，大約只有2個人能夠了解其實現(xiàn)過程。如果在早期采用MongoDB，團隊本有機會摒棄大部分相關的工作。

　　值得一提的是，高傲的開發(fā)者往往對新技術(shù)不夠耐心；或者說對新技術(shù)的能力或局限缺乏足夠耐心去了解。每一個產(chǎn)品都有其針對的問題域，對于問題域之外，新技術(shù)往往沒有成熟到能夠應對的地步。開發(fā)者需要不斷地閱讀、思考、參與，來驗證自己的問題域是否與其匹配。淺嘗輒止不是好的態(tài)度，也阻礙了新技術(shù)在團隊內(nèi)的推廣。

　　新技術(shù)的選型往往發(fā)生在項目/產(chǎn)品特定的時期，如開始階段，某個特定的痛點時期。日常階段，開發(fā)者仍然需要保持對代碼庫的關注。下一條，重構(gòu)為物理隔離的組件則是對不斷增大的代碼庫另一種解決方案。

　　1. 重構(gòu)為物理隔離的組件

　　顯而易見的趨勢是，對于同一個產(chǎn)品而言，需求總是不斷增多的。去年有100個功能，今年就有200個。去年有10萬行代碼，今年也許就有20萬行。去年2G 內(nèi)存的機器能夠正常開發(fā)，今年似乎得加倍才行。去年有15個開發(fā)人員，今年就到30個了。去年構(gòu)建一次最多15–20分鐘，今年就得1個小時了，還得整個分布式的。

　　有人會注意到代碼的設計問題，孜孜不倦地進行著重構(gòu)；有人會注意到構(gòu)建變慢的問題，不懈地改進著構(gòu)建時間。然而很少有人注意到代碼庫的變大才是問題的根源。很多常規(guī)的策略往往是針對組織的：例如將代碼庫按照功能模塊劃分（例如ABC功能之類）或者按層次劃分（例如持久層、表現(xiàn)層），但這些拆分之后的項目依然存在于開發(fā)人員的工作空間中。無論項目如何組織，開發(fā)者都需要打開所有的項目才能完成編譯和運行過程。我曾經(jīng)見到一個團隊需要在Visual Studio中打開120個項目；我自己也經(jīng)歷過需要在Eclipse中打開72個項目才能完成編譯。

　　解決方案是物理隔離這些組件。就像團隊在使用Spring/Hibernate/ASP.NET MVC/ActiveRecord這些庫的時候，不用將它們對應的源代碼放到工作空間進行編譯一樣，團隊也可以將穩(wěn)定工作的代碼單元整理出來形成對應的庫，標記版本然后直接引用二進制文件。

　　在不同的技術(shù)平臺上有著不同的方案。Java世界有歷史悠久的Maven庫，能夠良好的將不同版本的JAR以及他們的依賴進行管理；.NET比較遺憾，這方面真正成熟的什么也沒有（編者注：NuGet值得一試） —— 但參考Maven的實現(xiàn)，團隊自己造一個也不是難事（可能比較困難的是與MSBuild的集成）；Ruby/Rails世界則有著名的gem/bundler系統(tǒng)。將自己整理出來的比較獨立的模塊不要放到rails/lib /中，整理出來，形成一個新的gem，對其進行依賴引用（團隊內(nèi)需要搭建自己的gems庫）。

　　同時，代碼庫也需要進行大刀闊斧的整改。之前的代碼結(jié)構(gòu)可能如下，（這里以SVN為例，因為SVN有明確的trunk/branches/tags目錄結(jié)構(gòu)。git/hg類似）

　　原來的庫結(jié)構(gòu)

　　改進之后，將會如下圖所示：

　　改進的庫結(jié)構(gòu)

　　每個模塊都有屬于自己的代碼庫，擁有自己的獨立的升級和發(fā)布周期，甚至有自己的文檔。

　　這一方案看起來很容易理解，但在實際操作過程中則困難重重。團隊運轉(zhuǎn)很長一段時間之后，很少有人去關心模塊之間的依賴。一旦要拆分出來，去分析幾十上百個現(xiàn)存項目之間的依賴相當費勁。最簡單的處理辦法是，檢查代碼庫的提交記錄，例如最近3個月之內(nèi)某個模塊就沒有人提交過，那么這個模塊基本上就可以拿出來形成二進制依賴了。

　　很多開源產(chǎn)品都是通過這個過程形成的，例如Spring（請參考閱讀《J2EE設計開發(fā)編程指南》，Rod Johnson基本上闡述了整個Spring的設計思路來源）。一旦團隊開始這樣去思考，每隔一段時間重新審視代碼庫，你會發(fā)現(xiàn)核心代碼庫不可能失控，同時也獲得了一組設計良好、工作穩(wěn)定的組件。

　　2. 將獨立的模塊放入獨立的進程

　　上面的解決方案核心原則只有一條：始終將核心代碼庫控制在團隊可以理解的范圍內(nèi)。如果運轉(zhuǎn)良好，能夠很大程度上解決架構(gòu)因為代碼規(guī)模變大而腐化的問題。然而該解決方案只解決了系統(tǒng)在靜態(tài)層面的隔離。當隔離出的模塊越來越多，系統(tǒng)因此也需要越來越多的依賴來運行。這部分依賴在運行期分為兩類：一類是類似于Spring/Hibernate/Apache Commons之類的，系統(tǒng)運行的基礎，運行期這些必須存在；另外一類是相對獨立的業(yè)務功能，例如緩存的讀取，電子商城的支付模塊等。

　　第二類依賴則可以更進一步：將其放到獨立的進程中。現(xiàn)在稍具規(guī)模的系統(tǒng)，登錄、注銷功能已經(jīng)從應用中脫離而出，要么采用SSO的方案來進行登陸，要么則干脆代理給別的登陸系統(tǒng)。LiveJournal團隊在開發(fā)過程中，發(fā)現(xiàn)緩存的讀寫實際上可以放到獨立的進程中進行（而不是類似EhCache的方案，直接運行于所在的運行環(huán)境中），于是發(fā)明了現(xiàn)在鼎鼎有名的memcached. 我們之前進行的一個項目中，發(fā)現(xiàn)支付模塊完全能夠獨立出來，于是將其進行隔離，形成了一個新的、沒有界面的、永遠在運行的系統(tǒng)，通過REST處理支付請求。在另外一個出版項目中，我們發(fā)現(xiàn)編輯編寫報告的過程實際上與報告發(fā)行過程雖然存在類級別的重用，但在業(yè)務層面是獨立的。最終我們將報告發(fā)行過程做成了一個常駐服務，系統(tǒng)其他的模塊通過MQ消息與其進行交互。

　　這一解決方案應該不難理解。與解決方案1不同的是，這一方案更多的是要對系統(tǒng)進行面向業(yè)務層面的思考。由于系統(tǒng)將會以獨立的進程來運行這一模塊，在不同的進程中可能存在一定的代碼重復。例如Spring同時存在兩個不相關的項目中，大家覺得沒什么大不了的；但如果是自己的某個業(yè)務組件同時在同一個項目的兩個進程中重復，許多人就有些潔癖不可接受了。（題外話：這種潔癖在OSGi環(huán)境中也存在）這里需要提醒的是：當處于不同的進程時，它們在物理上、運行時上已經(jīng)徹底隔離了。必須以進程的觀點去思考整個架構(gòu)，而不是簡單的物理結(jié)構(gòu)。

　　從單進程模型到多進程模型的架構(gòu)思維轉(zhuǎn)變也不太容易 —— 需要架構(gòu)師有意識的加強這方面的練習。流行的.NET和Java世界傾向于把什么都放到一起。而Linux世界Rails/Django則能更好的平衡優(yōu)秀產(chǎn)品之間的進程協(xié)調(diào)。例如memcached的使用。另外，現(xiàn)在多核環(huán)境越來越多，與其費盡心思在編程語言層面上不如享受多核的好處，多進程能夠簡單并且顯著地利用多核能力。

　　3. 形成高度松散耦合的平臺+應用

　　現(xiàn)在將眼光看更遠一些。想象一下我們在做一個類似于開心網(wǎng)、Facebook、人人網(wǎng)的系統(tǒng)。它們的共同特點是能夠接入幾乎無限的第三方應用，無論是買賣朋友這類簡單的應用，還是絢麗無比的各種社交游戲。神奇的是，實現(xiàn)這一點并不需要第三方應用的開發(fā)者采用跟它們一樣的技術(shù)平臺，也不需要服務端提供無限的運算能力 —— 大部分的架構(gòu)由開發(fā)方來控制。

　　在企業(yè)應用中實現(xiàn)這個并不難。這其中的秘訣在于：當用戶通過Facebook訪問某個第三方應用的時候，F(xiàn)acebook實際上通過后臺去訪問了第三方應用，將當前用戶的信息（以及好友信息）通過HTTP POST送到第三方應用指定的服務網(wǎng)址，然后將應用的HTML結(jié)果渲染到當前頁面中。某種意義上說，這種技術(shù)本質(zhì)上是一種服務器端的mashup. （詳情參考InfoQ 文章）

　　Facebook App架構(gòu)

　　這種架構(gòu)的優(yōu)點在于極度的分布式。從外觀上看起來一致的系統(tǒng)，實際由若干個耦合極低、技術(shù)架構(gòu)完全不同的小應用組成。它們不需要被部署在同一臺機器上，可以單獨地開發(fā)、升級、優(yōu)化。一個應用的癱瘓不影響整個系統(tǒng)的運行；每個應用的自行升級對整個系統(tǒng)也完全沒有影響。

　　這并非是終極的解決方案，只在某些特定的條件下有效。當系統(tǒng)規(guī)模上非常龐大，例如由若干個子系統(tǒng)組成；界面基本一致；子系統(tǒng)之間關聯(lián)較少。針對這個前提，可以考慮采用這種架構(gòu)。抽象出極少的、真正有效公用的信息，在系統(tǒng)之間通過HTTP POST. 其他的系統(tǒng)完全可以獨立開發(fā)、部署，甚至針對應用訪問的情況進行特定的部署優(yōu)化。如果不這么做，動輒上百萬千萬行的代碼堆在一個系統(tǒng)中，隨著時間的推移，開發(fā)者逐漸對代碼失控，架構(gòu)的腐化是遲早的事情。

　　例如，銀行的財務系統(tǒng)，包括了十多個子系統(tǒng)，包括薪資、資產(chǎn)、報表等等模塊，每一部分功能都相對獨立并且復雜。整個系統(tǒng)如果按照這種方式拆分，就能夠?qū)崿F(xiàn)單點優(yōu)化而無需重新啟動整個應用。針對每個應用，開發(fā)者能夠在更小的代碼內(nèi)采用自己熟悉的技術(shù)方案，從而減少架構(gòu)腐化的可能。

　　結(jié)語

　　沒有糟糕的架構(gòu)，變化使之

　　我訪問過很多團隊。在很多項目開始的時候，他們花很多時間在選擇用何種技術(shù)體系，何種架構(gòu)，乃至何種IDE。就像小孩子選擇自己鐘愛的玩具，我相信無論過程如何，團隊最終都會欣然選擇他們所選擇的，并且堅信他們的選擇沒有錯誤。事實也確實如此。在項目的開始階段很難有真正的架構(gòu)挑戰(zhàn)。困難的地方在于，隨著時間的增長，人們會忘記；有很多的人加入，他們需要理解舊代碼的同時完成新功能；每一次代碼量的突破，都會引起架構(gòu)的不適應；這些不適應包括：新功能引入變得困難，新人難以迅速上手；構(gòu)建時間變長等等。這些能否引起團隊的警覺，并且采取結(jié)構(gòu)性的解決方案而不是臨時性的。

　　關于文檔

　　很多人說敏捷不提倡文檔。他們說文檔很難寫。他們說開發(fā)人員寫不了文檔。于是就沒有文檔。

　　奇怪的是我看到的情況卻不是這樣。程序?qū)懙脙?yōu)秀的人，寫起文字來也很不錯。ThoughtBlogs上絕大多數(shù)都是程序員，很多人的文字寫得都很贊。

　　而項目中的文檔往往少得可憐。新人來了總是一頭霧水。令人奇怪的是，新人能夠一天或者兩天之內(nèi)通過閱讀RSpec或者JBehave迅速了解這些工具的使用，到了團隊里面卻沒有了文檔。

　　拋開項目持續(xù)運轉(zhuǎn)并交付的特性不談，我認為巨大的、不穩(wěn)定的代碼庫是文檔迅速失效的根源。如果我們能夠按照上述的解決方案，將代碼庫縮小，那么獨立出來的模塊或者應用就有機會在更小的范圍內(nèi)具備更獨特的價值。想象一下現(xiàn)在的Rails3/Spring框架，他們往往有超過20個第三方依賴，我們卻沒有覺得理解困難，最重要的原因是依賴隔離之后，這些模塊有了獨立的文檔可以學習。

　　企業(yè)級項目也可以如此。

　　創(chuàng)建應用程序的生態(tài)環(huán)境，而非單一的項目

　　功能總是不斷的、不斷的加到同一個產(chǎn)品中。這毫不奇怪。然而通過我們前面的分析，我們應當重新思考這個常識。是創(chuàng)建一個日益龐大的、緩慢的、毫無生機的產(chǎn)品，還是將其有機分解，成為一個生機勃勃的具有不同依賴的生態(tài)系統(tǒng)？項目的各方人員（包括業(yè)務用戶、架構(gòu)師、開發(fā)者）應當從短視的眼光中走出來，著眼于創(chuàng)建可持續(xù)的應用程序生態(tài)系統(tǒng)。

it知識庫：架構(gòu)腐化之謎，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。