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