架構(gòu)決定最大利益
--在編寫(xiě)代碼之前確定好應(yīng)用程序性能和可伸縮性的限制
時(shí)間：2005-09-27
作者：Peter Varhol
瀏覽次數(shù)： 3527
本文關(guān)鍵字：設(shè)計(jì)模式, 架構(gòu), 應(yīng)用程序生命周期, 分布式系統(tǒng), 中間件?
應(yīng)用程序開(kāi)發(fā)的生命周期定義得非常好，許多軟件開(kāi)發(fā)小組都遵照它的某種變體進(jìn)行開(kāi)發(fā)。首先，要定義需求，接下來(lái)定義對(duì)軟件解決方案的一組要求。然后，依靠架構(gòu)師（或應(yīng)用程序設(shè)計(jì)人員，隨您怎么稱呼）的技能，定義應(yīng)用程序所需實(shí)現(xiàn)的功能，并繪制原理圖，以構(gòu)建應(yīng)用程序并將其映射到企業(yè)基礎(chǔ)架構(gòu)。
開(kāi)發(fā)人員根據(jù)該原理圖進(jìn)行編碼，直到包含了所有的功能，而且大多數(shù)的bug都已經(jīng)消除。最后，應(yīng)用程序被交給測(cè)試人員，他們可能按照需求進(jìn)行正式的測(cè)試，也可能只查找bug。但是，通過(guò)測(cè)試運(yùn)行的代碼，他們通常都能找出bug和其他缺陷，然后將其歸納、記錄，并返回給開(kāi)發(fā)人員從而解決。針對(duì)一個(gè)軟件版本，這個(gè)往返過(guò)程可能要花幾個(gè)月的時(shí)間，這取決于測(cè)試小組使用的質(zhì)量標(biāo)準(zhǔn)。
在傳統(tǒng)的生命周期中存在著隱患。通常測(cè)試人員是第一個(gè)對(duì)應(yīng)用程序的任意部分進(jìn)行非功能需求（這些需求定義的不是具體的功能，而是響應(yīng)性、當(dāng)前用戶的數(shù)量或正常運(yùn)行時(shí)間）測(cè)試的。猜猜會(huì)怎么樣？他們通常發(fā)現(xiàn)應(yīng)用程序存在缺陷，或者不能達(dá)到要求的用戶數(shù)量，或者響應(yīng)速度不夠快而造成不便。所以應(yīng)用程序又返回到開(kāi)發(fā)階段，進(jìn)行分析，并對(duì)某些部分進(jìn)行修改，但是修改的通常不是需要修改的部分。不管怎樣，最后它部署了，用戶就只好湊合使用；或者它被廢棄，成為又一個(gè)失敗的應(yīng)用程序開(kāi)發(fā)。
應(yīng)用程序其余的執(zhí)行時(shí)間都花在哪里了呢？答案是花在類庫(kù)、JVM或是數(shù)據(jù)庫(kù)的訪問(wèn)上了。可以采用一些策略改進(jìn)數(shù)據(jù)庫(kù)訪問(wèn)，比如使用鄰接原理(contiguity principle) 或其他算法在查詢時(shí)取出或緩存額外的數(shù)據(jù)。雖然這些策略有助于加速應(yīng)用程序，但是其作用有限，而且它們還會(huì)妨礙另一個(gè)重要目標(biāo)：可伸縮性。性能和可伸縮性必須在設(shè)計(jì)時(shí)考慮，而不是到編碼時(shí)才考慮。
應(yīng)用程序架構(gòu)設(shè)計(jì)拙劣的另一個(gè)原因是，由于較高的成本或技術(shù)上的限制，被取消或是大幅縮減的開(kāi)發(fā)項(xiàng)目的比例一直居高不下（據(jù)調(diào)查表明，通常是30%到70%）。許多因素造成了項(xiàng)目的失敗或取消，最常見(jiàn)的是需求的變化。但是很多情況下，不好的架構(gòu)也是原因之一。業(yè)務(wù)需求可以也肯定會(huì)隨時(shí)間改變，因此任何作為解決方案的架構(gòu)都必須將這個(gè)因素考慮在內(nèi)。靈活性強(qiáng)的架構(gòu)未必能成功，但是很可能會(huì)提高交付有用項(xiàng)目的幾率。
形勢(shì)與以前不一樣了，過(guò)去有可能通過(guò)巧妙地更改某些代碼而大大提升性能和可伸縮性，而今都是運(yùn)行在虛擬機(jī)上的分布式應(yīng)用程序，必須更改架構(gòu)才能達(dá)到相同的效果。每個(gè)開(kāi)發(fā)人員手中都只掌握了全部代碼的一小部分，而且做出了許多影響了性能的決策。
更改架構(gòu)比更改代碼更難，這有兩個(gè)原因。首先，更改架構(gòu)不是一項(xiàng)容易理解的行為，而它所需的技能也與更改代碼所需的技能完全不同。其次，架構(gòu)的更改必須在應(yīng)用程序生命周期的早期進(jìn)行。如果等到后期的編碼階段對(duì)應(yīng)用程序進(jìn)行測(cè)試時(shí)才定義架構(gòu)上的限制，那么已完成的應(yīng)用程序就很難被挽救了。
為什么會(huì)有如此多不適當(dāng)?shù)膽?yīng)用程序架構(gòu)呢？這有很多原因：
分布式系統(tǒng)還是比較新的事物。雖然總的來(lái)說(shuō)其優(yōu)點(diǎn)和局限性已經(jīng)為大家所知，但是要將這些一般性原理應(yīng)用到特定的應(yīng)用和基礎(chǔ)架構(gòu)中卻很困難。
因?yàn)檫@些系統(tǒng)比較新，所以有關(guān)設(shè)計(jì)和最佳實(shí)踐的信息傳播得還不夠廣，以至于企業(yè)的主要架構(gòu)師還不曾體驗(yàn)過(guò)新的設(shè)計(jì)實(shí)踐。
不同的應(yīng)用服務(wù)器及其他的中間件的性能和可伸縮性不同。此外，這些組件的調(diào)整要求也不同，通常需要專門(mén)的知識(shí)或細(xì)心的研究。
除了企業(yè)應(yīng)用程序需求的多樣性外，通常架構(gòu)師還被要求使用對(duì)于應(yīng)用程序來(lái)說(shuō)不是最佳的基礎(chǔ)架構(gòu)和中間件。這不是因?yàn)榧軜?gòu)師的能力或經(jīng)驗(yàn)不夠，而是因?yàn)樗麄兪苤朴诠ぷ鳜F(xiàn)實(shí)。
構(gòu)造目標(biāo)
最后一點(diǎn)需要特別注意。架構(gòu)師們被告知，或者自己認(rèn)為，必須按照已經(jīng)就緒的中間件和基礎(chǔ)架構(gòu)的參數(shù)工作。在許多情況下，這種約束就像試圖將一個(gè)方形的木柱打入一個(gè)圓形的洞一樣。例如，企業(yè)中網(wǎng)絡(luò)的最初設(shè)計(jì)目標(biāo)可能是針對(duì)來(lái)自PC服務(wù)器的文件，而不是針對(duì)來(lái)自基于Linux的應(yīng)用服務(wù)器的事務(wù)。
在某些情況下，這種不匹配是無(wú)法避免的。使用次優(yōu)的支持服務(wù)有時(shí)是迫不得已的。這里有一個(gè)折衷的問(wèn)題。糟糕的應(yīng)用服務(wù)器、不合適的網(wǎng)絡(luò)，或其他的基礎(chǔ)架構(gòu)組件可能促成不好的架構(gòu)——至少成為其借口。
這就是為什么在為新的分布式應(yīng)用程序確定架構(gòu)時(shí)只看應(yīng)用程序是不夠的。那些使架構(gòu)師能夠?qū)?yīng)用程序設(shè)計(jì)映射為基礎(chǔ)架構(gòu)參數(shù)的開(kāi)發(fā)方法，就很有可能識(shí)別限制應(yīng)用程序使其不能達(dá)到預(yù)定目標(biāo)的基礎(chǔ)架構(gòu)問(wèn)題。
確定提議的架構(gòu)可以應(yīng)用于現(xiàn)有的基礎(chǔ)架構(gòu)是一個(gè)好的開(kāi)端，但是并不能夠滿足針對(duì)特定的特性最優(yōu)化該架構(gòu)，或者重新配置基礎(chǔ)架構(gòu)以更好地遵從服務(wù)層協(xié)議的需求。對(duì)于在編碼開(kāi)始之前確保能夠很好地滿足性能和可伸縮性目標(biāo)，架構(gòu)師負(fù)有很大的責(zé)任。
在構(gòu)建應(yīng)用程序架構(gòu)方面，有很多輔助程序。Sun Microsystems的模式和最佳實(shí)踐Web站點(diǎn)提供了許多設(shè)計(jì)模式，其中大多數(shù)都是架構(gòu)模式而不是編碼模式，因此是一個(gè)很好的起點(diǎn)。微軟提供了其Web站點(diǎn)的應(yīng)用程序架構(gòu)部分，其中有大量的設(shè)計(jì)模式和其他的一些建議。雖然其中許多模式使用的都是微軟的技術(shù)，但是那些建議則普遍適用于任何分布式應(yīng)用程序。
有哪些架構(gòu)模式可用？廣泛使用的模型-視圖-控制器(Model-View-Controller，MVC) 模式及其很多變體是很好的代表，另外還有安全性、身份驗(yàn)證和授權(quán)等主題。數(shù)據(jù)管理和訪問(wèn)被作為在應(yīng)用層之間傳遞數(shù)據(jù)的策略進(jìn)行討論。所有這些以及其他模式對(duì)于設(shè)計(jì)分布式應(yīng)用程序的最優(yōu)性能和可伸縮性都是有用的模式。
除了這些建議、其他來(lái)源的建議，以及咨詢公司的服務(wù)，似乎還缺少一個(gè)并非推薦特定產(chǎn)品或解決方案的最佳實(shí)踐綱要。問(wèn)題是這樣的集合將會(huì)隨形勢(shì)而不斷變化，因?yàn)橛腥绱硕嗟囊蛩赜绊懼植际綉?yīng)用程序的最優(yōu)化。但是，存在足夠多的不同來(lái)源和模式，可以為架構(gòu)師提供有關(guān)在大多數(shù)平臺(tái)和中間件下設(shè)計(jì)分布式應(yīng)用程序并配置應(yīng)用程序組件的各種建議和方向。
對(duì)架構(gòu)師進(jìn)行良好的教育和培訓(xùn)也是因素中的一部分。例如，我還沒(méi)有看到關(guān)于應(yīng)用程序架構(gòu)的大學(xué)課程（如果確實(shí)存在請(qǐng)告訴我）。大多數(shù)情況下，大學(xué)的課程都只重視對(duì)整個(gè)應(yīng)用程序或單個(gè)應(yīng)用程序組件的編碼，而一般都忽略了分布式應(yīng)用程序。這種不好的局面必須改變，這樣才能培養(yǎng)出可以開(kāi)發(fā)現(xiàn)實(shí)世界的分布式系統(tǒng)架構(gòu)的專業(yè)人員。
給架構(gòu)師的建議
總而言之，從現(xiàn)在開(kāi)始，軟件開(kāi)發(fā)小組和用戶代表需要重視應(yīng)用程序架構(gòu)了，要將其看作是編碼之前的一個(gè)關(guān)鍵步驟。雖然當(dāng)今的IDE和應(yīng)用程序框架使編碼變得輕松了，但是它們對(duì)架構(gòu)毫無(wú)幫助。我將試著找出解決的方法。
我的計(jì)劃是進(jìn)行架構(gòu)審查，在這個(gè)過(guò)程中所有涉眾（包括用戶）都看到了關(guān)于新應(yīng)用程序的提議架構(gòu)的演示文稿，包括為什么采用這種架構(gòu)，該架構(gòu)對(duì)哪些部分進(jìn)行了最優(yōu)化，以及進(jìn)行了哪些折衷。當(dāng)然了，審查是由架構(gòu)師主持的，而且他或她的任務(wù)是使涉眾相信，該架構(gòu)符合每個(gè)人的最大利益。自然會(huì)有一些目標(biāo)互相沖突，必須通過(guò)妥協(xié)才能解決，但是最終結(jié)果是產(chǎn)生一個(gè)業(yè)務(wù)目標(biāo)和技術(shù)目標(biāo)都能最大程度地得到滿足的架構(gòu)。使要編碼的應(yīng)用程序可以實(shí)現(xiàn)它必須實(shí)現(xiàn)的性能和可伸縮性要求的策略還有待不斷地完善和發(fā)展。
參考資料
FTPOnline上的“The Business Perception of MDA”，由Java Pro的編輯撰寫(xiě)，2005年4月6日。
原文出處
http://www.ftponline.com/javapro/2005_06/magazine/columns/objectenterprise/?sid=rssfeed_channelJava
?作者簡(jiǎn)介?
Peter Varhol是Compuware公司的技術(shù)專家.