?什么是軟件系統的架構（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服務元件、安全服務元件、系統管理元件等。

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

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

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

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

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

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

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

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

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

架構師

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

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

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

---

好的開始相當于成功一半

開始之初的架構設計決定著軟件產品的生死存亡。“好的開始相當于成功一半”。

開始的架構設計也是最難的，需要調研同類產品的情況以及技術特征，了解當前世界上對這種產品所能提供的理論支持和技術平臺支持。再結合自己項目的特點(需要透徹的系統分析)，才能逐步形成自己項目的架構藍圖。

比如要開發網站引擎系統，就從Yahoo的個人主頁生成工具 到虛擬主機商提供的網站自動生成系統，以及IBM Webphere Portal的特點和局限 從而從架構設計角度定立自己產品的位置。

好的設計肯定需要經過反復修改，從簡單到復雜的循環測試是保證設計正確的一個好辦法

由于在開始選擇了正確的方向，后來項目的實現過程也驗證了這種選擇，但在一些架構設計的細部方面，還需要對方案進行修改，屬于那種螺旋上升的方式，顯然這是通過測試第一的思想和XP工程方法來實現的。

如果我們開始的架構設計在技術平臺定位具有一定的世界先進水平，那么，項目開發實際有一半相當于做實驗，是研發，存在相當的技術風險。

因此，一開始我們不可能將每個需求都實現，而是采取一種簡單完成架構流程的辦法，使用最簡單的需求將整個架構都簡單的完成一遍（加入人工干預），以檢驗各個技術環節是否能協調配合工作(非常優秀先進的兩種技術有時無法在一起工作)，同時也可以探知技術的深淺，掌握項目中的技術難易點。這個過程完成后，我們就對設計方案做出上面的重大修改，豐富完善了設計方案。

設計模式是支撐架構的重要組件

架構設計也類似一種工作流，它是動態的，這點不象建筑設計那樣，一開始就能完全確定，架構設計伴隨著整個項目的進行過程之中，有兩種具體操作保證架構設計的正確完成，那就是設計模式(靜態)和工程項目方法(RUP或XP 動態的)。

設計模式是支撐架構的一種重要組件，這與建筑有很相象的地方，一個建筑物建立設計需要建筑架構設計，在具體施工中，有很多建筑方面的規則和模式。

我們從J2EE藍圖模式分類http://java.sun.com/blueprints/patterns/catalog.html中就可以很清楚的看到J2EE這樣一個框架軟件的架構與設計模式的關系。

架構設計是骨架，設計模式就是肉

這樣，一個比較豐富的設計方案可以交由程序員進一步完成了，載輔助以適當的工程方法，這樣就可保證項目的架構設計能正確快速的完成。

時刻牢記架構設計的目標

由于架構設計是在動態中完成的，因此在把握架構設計的目標上就很重要，因此在整個項目過程中，甚至每一步我們都必須牢記我們架構設計的總體目標，可以概括下面幾點：

1. 最大化的重用：這個重用包括組件重用 和設計模式使用等多個方面。

比如，我們項目中有用戶注冊和用戶權限系統驗證，這其實是個通用課題，每個項目只是有其內容和一些細微的差別，如果我們之前有這方面成功研發經驗，可以直接重用，如果沒有，那么我們就要進行這個子項目的研發，在研發過程中，不能僅僅看到這個項目的需求，也要以架構的概念去完成這個可以稱為組件的子項目。

2. 盡可能的簡單明了：我們解決問題的總方向是將復雜問題簡單化，其實這也是中間件或多層體系技術的根本目標。但是在具體實施設計過程中，我們可能會將簡單問題復雜化，特別是設計模式的運用上很容易范這個錯誤，因此如何盡可能的做到設計的簡單明了是不容易的。

我認為落實到每個類的具體實現上要真正能體現系統事物的本質特征，因為事物的本質特征只有一個，你的代碼越接近它，表示你的設計就是簡單明了，越簡單明了，你的系統就越可靠。更多情況是，一個類并不能反應事物本質，需要多個類的組合協調，那么能夠正確使用合適的設計模式就稱為重中之重。

我們看一個具備好的架構設計的系統代碼時，基本看到的都是設計模式，寵物店(pet store)就是這樣的例子。或者可以這樣說，一個好的架構設計基本是由簡單明了的多個設計模式完成的。

3. 最靈活的拓展性：架構設計要具備靈活性 拓展性，這樣，用戶可以在你的架構上進行二次開發或更加具體的開發。

要具備靈活的拓展性，就要站在理論的高度去進行架構設計，比如現在工作流概念逐步流行，因為我們具體很多實踐項目中都有工作流的影子，工作流中有一個樹形結構權限設定的概念就對很多領域比較通用。

樹形結構是組織信息的基本形式，我們現在看到的網站或者ERP前臺都是以樹形菜單來組織功能的，那么我們在進行架構設計時，就可以將樹形結構和功能分開設計，他們之間聯系可以通過樹形結構的節點link在一起，就象我們可以在圣誕樹的樹枝上掛各種小禮品一樣，這些小禮品就是我們要實現的各種功能。

有了這個概念，通常比較難實現的用戶級別權限控制也有了思路，將具體用戶或組也是和樹形結構的節點link在一起，這樣就間接實現了用戶對相應功能的權限控制，有了這樣的基本設計方案的架構無疑具備很靈活的拓展性。

轉載于:https://blog.51cto.com/wellbeing/358992

總結

以上是生活随笔為你收集整理的软件系统的架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。