什麼是軟體系統的架構（Architecture）?

什麼是軟體系統的架構（Architecture）。一般而言，架構有兩個要素：

　　·它是一個軟體系統從整體到部分的最高層次的劃分。

　　一個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要訊息。

　　詳細地說，就是要包括架構元件（Architecture Component）、連接器（ Connector ）、任務流（ Task -flow）。所謂架構元素，也就是組成系統的核心"磚瓦"，而連接器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和連接器完成某一項需求。

　　·建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。

　　在建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關係統設計成敗的最重要決定，必須經過非常謹慎的研究和考察。

　　電腦軟體的曆史開始於五十年代，曆史非常短暫，而相比之下建築工程則從石器時代就開始了，人類在幾千年的建築設計實踐中積累了大量的經驗和教訓。建築設計基本上包含兩點，一是建築風格，二是建築模式。獨特的建築風格和恰當選擇的建築模式，可以使一個獨一無二。

　　下面的照片顯示了中美洲古代瑪雅建築，Chichen-Itza大金字塔，九個巨大的石級堆壘而上，九十一級台階（象徵著四季的天數）奪路而出，塔頂的神殿聳入雲天。所有的數字都如日曆般嚴謹，風格雄渾。難以想象這是石器時代的建築物。

圖1、位於墨西哥Chichen-Itza（在瑪雅語中chi意為嘴chen意為井）的古瑪雅建築。（攝影：作者）

　 　軟體與人類的關係是架構師必須面對的核心問題，也是自從軟體進入曆史舞台之後就出現的問題。與此類似地，自從有了建築以來，建築與人類的關係就一直是建 築設計師必須面對的核心問題。英國首相丘吉爾說，我們構造建築物，然後建築物構造我們（We shape our buildings, and afterwards our buildings shape us）。英國下議院的會議廳較狹窄，無法使所有的下議院議員面向同一個方向入座，而必須分成兩側入座。丘吉爾認為，議員們入座的時候自然會選擇與自己政見 相同的人同時入座，而這就是英國政黨制的起源。Party這個詞的原意就是"方"、"面"。政黨起源的關鍵就是建築物對人的影響。

　　在軟體設計界曾經有很多人認為功能是最為重要的，形式必須服從功能。與此類似地，在建築學界，現代主義建築流派的開創人之一Louis Sullivan也認為形式應當服從於功能（Forms follows function）。

　　幾乎所有的軟體設計理念都可以在浩如煙海的建築 學曆 史中找到更為遙遠的曆史迴響。最為著名的，當然就是模式理論和XP理論。

　　架構的目標是什麼

　　正如同軟體本身有其要達到的目標一樣，架構設計要達到的目標是什麼呢。一般而言，軟體架構設計要達到如下的目標：

　　·可靠性（Reliable）。軟體系統對於使用者的商業經營和管理來說極為重要，因此軟體系統必須非常可靠。

　　·安全行（ Secure ）。軟體系統所承擔的交易的 商業價值 極高，系統的 安全性 非常重要。

　　·可擴充性（Scalable）。軟體必須能夠在使用者的使用率、使用者的數目增加很快的情況下，保持合理的效能。只有這樣，才能適應使用者的市場擴充得可能性。

　　·可定製化（Customizable）。同樣的一套軟體，可以根據客戶群的不同和市場需求的變化進行調整。

　　·可擴充性（Extensible）。在新技術出現的時候，一個軟體系統應當允許匯入新技術，從而對現有系統進行功能和效能的擴充

　　·可維護性（Maintainable）。軟體系統的維護包括兩方面，一是排除現有的 錯誤， 二是將新的軟體需求反映到現有系統中去。一個易於維護的系統可以有效地降低支援人員的花費

　　·客戶體驗（Customer Experience）。軟體系統必須便於使用。

　　·市場時機（ Time to Market）。軟體使用者要面臨同業競爭，軟體供應商也要面臨同業競爭。以最快的速度爭奪市場先機非常重要。

　　架構的種類

　　根據我們關注的角度不同，可以將架構分成三種：

　　·邏輯架構、軟體系統中元件之間的關係，比如使用者介面，資料庫，外部系統介面，商業邏輯元件，等等。

　　比如下面就是筆者親身經曆過的一個軟體系統的邏輯架構圖

圖2、一個邏輯架構的例子

　　從上面這張圖中可以看出，此系統被劃分成三個邏輯層次，即表象層次，商業層次和資料持久層次。每一個層次都含有多個邏輯元件。比如 WEB服務 器層次中有 HTML 服務元件、Session服務元件、 安全服務 元件、 系統管理 元件等。

　　·物理架構、軟體元件是怎樣放到硬體上的。

　　比如下面這張物理架構圖描述了一個分佈於北京和上海的 分布式 系統的物理架構，圖中所有的元件都是物理裝置，包括網路分流器、Proxy 伺服器、 WEB服務 器、應用伺服器、報表伺服器、整合伺服器、 儲存服務 器、主機等等。

圖3、一個物理架構的例子

　　·系統架構、系統的非功能性特徵，如可擴充性、可靠性、強壯性、靈活性、效能等。

　　系統架構的設計要求架構師具備軟體和硬體的功能和效能的過硬知識，這一工作無疑是架構設計工作中最為困難的工作。

　　此外，從每一個角度上看，都可以看到架構的兩要素：元件劃分和設計決定。

　　首先，一個軟體系統中的元件首先是邏輯元件。這些邏輯元件如何放到硬體上，以及這些元件如何為整個系統的可擴充性、可靠性、強壯性、靈活性、效能等做出貢獻，是非常重要的資訊。

　　其次，進行軟體設計需要做出的決定中，必然會包括邏輯結構、物理結構，以及它們如何影響到系統的所有非功能性特徵。這些決定中會有很多是一旦作出，就很難更改的。

　　根據作者的經驗，一個基於資料庫的系統架構，有多少個資料表，就會有多少頁的架構設計文檔。比如一個中等的 資料庫應用 系統通常含有一百個左右的資料表，這樣的一個系統設計通常需要有一百頁左右的架構設計文檔。

　　架構師

　　軟體設計師中有一些技術水平較高、經驗較為豐富的人，他們需要承擔軟體系統的架構設計，也就是需要設計系統的元件如何劃分、元件之間如何發生相互作用，以及系統中邏輯的、物理的、系統的重要決定的作出。

　　這樣的人就是所謂的架構師（Architect）。在很多公司中，架構師不是一個專門的和正式的職務。通常在一個開發小組中，最有經驗的程式員會負責一些架構方面的工作。在一個部門中，最有經驗的專案經理會負責一些架構方面的工作。

　　但是，越來越多的公司體認到架構工作的重要性，並且在不同的組織層次上設定專門的架構師位置，由他們負責不同層次上的邏輯架構、物理架構、系統架構的設計、配置、維護等工作。