軟件架構的重要性在于它會(huì )影響整個(gè)軟件系統。只有審慎地選擇軟件架構，才能降低風(fēng)險，避免失敗。
架構扮演著(zhù)系統骨架的角色。無(wú)論開(kāi)發(fā)者是否有意選擇架構，所有系統皆有架構。對于軟件系統而言，世上雖不存在唯一正確的架構，不過(guò)或多或少都有適合的系統骨架。
軟件架構師
架構影響質(zhì)量屬性。質(zhì)量屬性是外部可見(jiàn)的，例如，安全性、可用性、延遲時(shí)間或可修改性。不同的系統骨架在處理不同的系統負荷時(shí)，會(huì )有優(yōu)劣之分，因此，挑選恰當的架構會(huì )更容易滿(mǎn)足質(zhì)量屬性。架構與功能(基本上)是正交的對于同一系統而言，既可能構建為三層架構，也可能構建為對等網(wǎng)絡(luò )系統。然而一旦架構與功能匹配欠佳，開(kāi)發(fā)者就要努力克服之。
架構是對系統的約束。架構是對系統恰如其分地施加約束，以便系統獲得我們所需質(zhì)量屬性的一門(mén)藝術(shù)。例如，為了確?？缮炜s性，或許就會(huì )要求一些組件是無(wú)狀態(tài)的。下面將依次闡述這些觀(guān)點(diǎn)。
架構是對系統的約束
架構是系統的骨架。骨架作為架構的隱喻，雖有不足卻很有用。骨架為動(dòng)物提供了整體結構，以支撐其行動(dòng)。鳥(niǎo)之所以善飛，袋鼠之所以善跳，完全得益于它們各自的骨架。大多數行動(dòng)迅捷的動(dòng)物都擁有四條腿，而兩條腿的動(dòng)物雖然行動(dòng)會(huì )慢些，卻更善于使用工具。除非你說(shuō)跳比飛好，否則就不能說(shuō)一種骨架優(yōu)于另一種骨架。你可以說(shuō)一種骨架是否很好地適合其功能，例如，要讓袋鼠的骨架適于飛翔，勢必要大費周章。
軟件亦如是。三層架構使得信息技術(shù)系統可以把變更限制在局部范圍，并能處理事務(wù)性的負載。之所以協(xié)作進(jìn)程架構更適合操作系統，是因為它能夠隔離故障。很難想象，類(lèi)似Skype的分布式VOIP網(wǎng)絡(luò )系統若不使用對等網(wǎng)絡(luò )架構，會(huì )是怎樣的情形。
然而，之所以說(shuō)骨架的隱喻存在不足，是因為架構并不僅僅是那些外部可見(jiàn)的主體部分(即骨骼)，某些不可見(jiàn)部分(如約束)通常更重要。例如，鎖策略、內存管理策略或者集成第三方組件的技術(shù)，都可以是架構的一部分，而在運行的系統或源代碼中，這些內容都是不可見(jiàn)的。
架構師
架構影響質(zhì)量。開(kāi)發(fā)者必須關(guān)注其軟件做了什么，即軟件的功能。要是財會(huì )軟件不能管理賬務(wù)，動(dòng)畫(huà)軟件不能制作動(dòng)畫(huà)，對于這樣的軟件，只能棄之如履。此外，系統還包含許多與功能無(wú)關(guān)的額外需求，通常稱(chēng)之為質(zhì)量屬性需求。同樣，開(kāi)發(fā)者必須重視質(zhì)量屬性需求，因為要是財會(huì )軟件如果讓別有居心的家伙讀取到保密賬戶(hù)，或者動(dòng)畫(huà)軟件的運行速度異常緩慢，都會(huì )讓人選擇放棄。
系統架構不僅要支持所需的功能，同時(shí)還能夠促進(jìn)或抑制諸如安全或性能等系統質(zhì)量。盡管人和馬的身體骨架都支持運輸蘋(píng)果到市場(chǎng)的功能，但在運輸效率和數量上卻相差甚遠。選擇一種架構使得系統能夠工作并非難事，但在滿(mǎn)足質(zhì)量屬性方面，有的選擇是事半功倍，有的選擇則會(huì )事倍功半。
功能隨著(zhù)時(shí)間的推移而演化，這對于任何一個(gè)系統都是一種挑戰，而質(zhì)量屬性的演化卻會(huì )迫使系統產(chǎn)生劇變。設計一個(gè)系統，使其從支持一百名用戶(hù)擴展到十萬(wàn)名，要想不改變架構，幾乎不可能做到。我們經(jīng)?？梢钥吹?，應用系統持續不斷的變遷與波動(dòng)，導致舊有的架構無(wú)法滿(mǎn)足其增長(cháng)，這有些像螃蟹的軀體變得越來(lái)越大，超過(guò)了它所寄居的蟹殼。
架構與功能(基本上)是正交的。沒(méi)有一個(gè)放之四海而皆準的最佳架構，就像動(dòng)物的骨架一般，各有所長(cháng)，各有所短。要是袋鼠擁有了中空骨骼，那跳躍時(shí)就非常容易折斷，要是鳥(niǎo)兒擁有了強壯的雙腿，那飛起來(lái)就會(huì )像鴕鳥(niǎo)一樣笨拙。另一方面，可能會(huì )選定一種骨架，并迫使其在不適宜的環(huán)境下工作。例如，魚(yú)類(lèi)可以在水中呼吸，哺乳動(dòng)物卻不能。然而，鯨盡管屬于哺乳動(dòng)物，卻能打破這一約束而生活在水中，雖然要費些周折。
軟件架構師需要不斷地思考
重要的是，我們要認識到架構與功能可以相互混合，取長(cháng)補短。我們可以改變系統的架構并保持功能不變；抑或在提供不同功能的系統上重用同一套架構。不過(guò)，二者的組合取得的效果不盡相同，或者珠聯(lián)璧合，或者水火不容。
雖然對系統架構的選擇與功能是相互獨立的，但糟糕的架構決策總是會(huì )給功能與質(zhì)量屬性的實(shí)現帶來(lái)障礙。這就好比工廠(chǎng)制造的產(chǎn)品與其所處的地理位置屬于兩個(gè)截然不同的維度，你完全可以在二者彼此獨立的情況下作出抉擇。要在大漠之中修建船廠(chǎng)也非不可，不過(guò)要將造好的船只拖到港口，就得費九牛二虎之力了。只要你能付出足夠的努力，無(wú)論選擇哪種架構都可以構建出各種系統，然而，一旦架構選擇失當，開(kāi)發(fā)者就會(huì )舉步維艱。
架構約束程序。任何系統皆有約束。某些系統需要與舊有系統進(jìn)行互操作，某些系統強制要求使用指定供應商的子組件，還有的系統則必須滿(mǎn)足內存或時(shí)間的預算。這些約束常常被視為絆腳石，它們使得開(kāi)發(fā)者的工作變得更為棘手；然而，不妨換種思路去看待這些約束。
在設計系統時(shí)，你的選擇會(huì )將系統限制為某種工作方式，而不是另一種。有時(shí)這些選擇是隨意而為的。不過(guò)有些選擇卻可以限制系統具有某種意圖，從而引導系統到達所選擇的目的地。對于系統建設、系統執行作業(yè)的能力及與時(shí)俱進(jìn)的維護能力而言，此類(lèi)約束條件起著(zhù)導軌的作用，并且至關(guān)重要。
研究系統建設
設計系統時(shí)，可以約束實(shí)現方法的唯一性。有時(shí)候，這些選擇顯得隨意而為；然而，有些選擇卻可以指導系統的設計走向期望達到的目標。這樣的約束起到了指南針的作用，是構造一個(gè)系統必需的行動(dòng)指南，既可以指導工作的實(shí)現，又能夠隨著(zhù)時(shí)間的變遷，有助于維護整個(gè)系統。
系統不做什么與系統能做什么同等重要。要確保系統具備特定的質(zhì)量屬性，就必須施加約束，以便明示那些不能做的事情。例如，安全的系統不會(huì )與不可信的第三方交換數據，而可用的系統不會(huì )在沒(méi)有提供取消選項的情況下就啟動(dòng)長(cháng)時(shí)間運行的計算。
為了實(shí)現性能或安全等質(zhì)量要求，可以主動(dòng)對自己的設計進(jìn)行約束。例如，火車(chē)受到軌道的約束，因而行駛路線(xiàn)缺乏靈活性。但是，這種約束卻有助于其他的質(zhì)量要求，例如，車(chē)輪與軌道的摩擦力較小，因而可以提高行進(jìn)速度。隨之帶來(lái)的好處還有安全，因為要劫持一輛火車(chē)相對比較困難。從字面上講，不受限制的設計可以做任何事情，因此若是希望對系統進(jìn)行分析，就必須給予限制。關(guān)于約束的使用貫穿本書(shū)始終，隨后我們會(huì )回來(lái)繼續討論，并提供更為詳盡的例子。
工程師通過(guò)約束來(lái)保證設計的系統滿(mǎn)足其意圖。只要運用得當，就可以從約束中獲益良多：
體現判斷。約束有利于知識在開(kāi)發(fā)者之間的傳遞，便于達成共識。資深工程師對行業(yè)的了解更加細致而深入，但卻要花費時(shí)間才能將此類(lèi)知識傳遞給其他人。通過(guò)對設計進(jìn)行約束，就可以指導其他工程師接受解決方案，無(wú)須完整地傳遞他們所擁有的知識。
軟件開(kāi)發(fā)需要一個(gè)好的架構
促進(jìn)概念完整性。FredBrooks認為，系統的概念完整性是系統設計的重要目標，因此運用一個(gè)始終如一的好主意勝過(guò)幾個(gè)散布于系統各處的奇思妙想。Souza持有相同觀(guān)點(diǎn)，他在談到架構約束時(shí)，認為開(kāi)發(fā)者應該“減少不必要的創(chuàng )新”，將這種創(chuàng )新力放到需要的地方。
降低復雜度。作為概念完整性的必然結果，約束可以化繁為簡(jiǎn)，從而使得就此構建的系統具有顯而易見(jiàn)的基本原則。相比之下，沒(méi)有約束的系統則可能以任意不同的方式在不同的地方去完成類(lèi)似的工作，從而影響對系統的理解，除非能夠完全掌握系統的所有細枝末節。約束提供了明確的做法，可以砍掉此類(lèi)復雜性。例如，如果數據只能保存至某個(gè)數據庫，那么你就能知道該去哪里找數據。
理解運行時(shí)行為。雖然可以直接審查源代碼，但卻難以預測其運行時(shí)行為?？梢跃帉?xiě)出晦澀艱深的代碼，使其運行時(shí)行為令人費解；抑或對其加以約束，從而使其運行時(shí)行為變得顯而易見(jiàn)。
在某些時(shí)候，你可能會(huì )抱怨系統施加的約束讓人變得縮手縮腳。雖然確有約束使用不當的情況發(fā)生，然而離開(kāi)了約束，設計就無(wú)從談起。不能因噎廢食，因為約束可以使得混亂歸于井然有序，而這種混亂恰好是工程師的大敵。必須妥善地對系統施加約束，而不能全盤(pán)否定。對系統架構的設計就是對決策進(jìn)行推敲與取舍，判斷什么該做，什么不能做。任何對于施加約束的猶疑不定都不會(huì )來(lái)自對它們的明智使用，而是來(lái)自其他人草率、無(wú)知的濫用約束方式。
聯(lián)系客服
