學習軟體架構知識是為了站在較高層面上整體地解決好軟體的設計、複用、品質和維護等方面的實際問題。
一、概述
（一）軟體架構的重要性
1、項目關系人交流的平台
2、早期設計決策
1）明确對系統實作的限制條件
2）預測系統的品質
3）維護決策提供根據
4）有助于原型開發
5）估計成本與進度
3、在較高層面上實作軟體複用
4、指導和規範開發
傳統軟體開發模式中，軟體架構應位于概要設計之前，需求分析之後；
而基于架構的軟體開發模型則将整個軟體過程劃分為架構需求、設計、文檔化、評審（評估）、實作、演化等6部分。
(二)架構模型
軟體架構可歸納為結構模型，架構模型，動态模型，過程模型，功能模型5種，但各有所長，将它們有機統一起來也許更合适，是以有人提出了“4+1”視圖模型：
二、架構需求與軟體品質屬性
軟體屬性包括功能屬性和品質屬性。軟體架構重點關注品質屬性。因為實作功能的方法多種多樣，架構師要權衡利弊。軟體架構在滿足功能屬性的前提下，尋找合适的套路來提升軟體品質屬性。
（一）軟體品質屬性
1、可用性
2、可修改性
3、性能
4、安全性
5、可測試性
6、易用性
各個品質屬性之間互相制約或互相促進，需要衡量。
按項目階段又可分為
開發期品質屬性
運作期品質屬性
1、可用性及其實作
故障處置。
1）錯誤檢測
日志 心跳 異常捕捉
2）錯誤恢複
備援，備件，復原，事務，降級
3）錯誤預防
事務等
2、可修改性及其實作
1）将修改限制在局部
高内聚低耦合，降低對其他子產品的依賴；提高子產品的通用性；限制變更範圍等；
2）防止連鎖反應
對擴充開放， 對更改關閉。
3）推遲綁定時間
配置檔案，多态，注冊
3、性能及其實作
1）減少及控制資源使用
2）資源管理
引入并發，緩存，增加資源
3）資源仲裁
資源排程
4、安全性及其實作
1）防禦攻擊
2）檢測攻擊
3）恢複
5、可測試性及其實作
1）輸入輸出
記錄，接口與實作分離，用實作替代用于測試
2）内部監控
6、易用性及其實作
1）運用時
記錄使用者習慣，收集使用者回報
2）設計時
使用者接口獨立
3）支援使用者主動操作
三、軟體風格
軟體架構設計的一個核心問題是複用架構。基于此，帶出軟體架構的風格和類型問題。
軟體架構風格為大粒度的軟體重用提供了可能。
（一）軟體架構風格分類
1、資料流風格
順序執行。包括批處理序列和管道/過濾器。2、調用/傳回風格
系統采用了調用與傳回機制，實質是一種分而治之的政策，主要思想為将複雜的大系統分解為若幹子系統，降低複雜度，增加可修改性。
包括
1）主程式/子程式
2）面向對象風格
對象通過函數和方法進行互動。
3）層次結構風格
上層調用下層。
CS、BS、MVC、MVP都屬于層次結構。
3、獨立構件風格
強調系統中的每個構件都是相對獨立的個體，它們之間不直接通信，以降低耦合度，提升靈活性。包括：
1）程序通信
通過消息傳遞來連接配接構件
2）事件子系統
基于事件的隐式調用風格。系統不直接調用構件，構件的過程注冊到事件，當事件被觸發，則注冊于其中的所有構件都被執行。觀察者模式。
我認為主要事件系統的優點在于調用和被調用沒有直接關聯，解耦。4、虛拟機風格
人為建構一個運作環境，系統運作于其中，可以解析與運作自定義的語言，增加架構的靈活性。包括
1）解釋器
2）以規則為中心
5、倉庫風格
一個中央資料庫，獨立的構件圍繞其上執行。
1）資料庫
2）超文本系統
3）黑闆。黑闆相當于共享資料。知識源通過黑闆互動。
四、面向服務的架構（SOA）
所有功能都定義成獨立的服務，服務之間通過互動和協調完成業務的整體邏輯。所有服務通過服務總線或流程管理器來連接配接。松散耦合，各服務無需考慮對方的内部實作細節，以及部署在什麼平台上。
(一)、SOA的關鍵技術
SOA關鍵技術有UDDI、WSDL、SOAP和REST，都以XML為基礎發展而來。
1）UDDI 服務釋出、查找及定位
2）WSDL 服務描述
3）SOAP 服務之間消息傳輸規範
4）REST
(二)、SOA的實作方法
SOA隻是一種概念和思想，需要具體實作。
1、WebService
現實是往往是将WebService和SOA混為一談。但WebService隻是SOA的一個具體實作。或者也可以這麼說，正是有了WebService，SOA才得以落地和推廣。
2、企業服務總線（ESB）
一種為支撐SOA的統一通信環境。所有的服務都可以接入ESB來互相通路。服務利用ESB而不是直接互相通路，是以應該是中介者模式。
ESB具有服務功能，例如可負責在諸多服務之間轉換業務邏輯和資料格式。如此說來，又是擴充卡模式。ESB還能在現有系統不更改代碼的情況下，讓現有系統具備全新的對外服務接口。ESB還提供安全機制。另外，ESB好像還提供了工作流？
聽上去，ESB就是一種服務之間的粘合劑，萬金油。但我實在想不出它是個什麼鬼。
（三）微服務
微服務也屬于SOA的一個概念。傳統意義上的SOA，是跨系統的，不同的系統做成不同的服務，粗粒度；而微服務則是将一個程式再細分成若幹個微服務，細粒度。
其優勢是可以針對不同的功能，細分成不同的微服務，進而選用不同的技術和産品，比如用文檔型資料庫來存儲文章内容，用圖資料來存儲朋友圈，或者用于測試新技術，等等。其他像系統彈性、擴充、簡化部署、組合等都有優勢。
缺點主要是增加了複雜度，以及系統的不穩定性。這是一種綜合衡量的結果。一方面，劃分成不同的微服務，可能有利于清晰業務邏輯，降低了整個系統的耦合程度，變簡單了；但本來一個系統，現在是幾個小系統，系統多了，又算複雜了；本來單個系統，有一個地方報錯，很可能整個系統都崩潰，但劃分成微服務後，單個故障，其他還能用，增強了系統的可用性；但因為多個微服務之間通信，很可能是分布式的，反而帶來更多的不确定性因素。
五、架構設計
架構風格就是架構模式。這些模式都有相應的套路，在高層抽象層次上具有普遍實用性和複用性。通過架構模式，架構設計師可以借鑒和複用他人的經驗，看看類似的問題别人是如何解決的，但這隻是一種解決問題的思路，并非硬性規定。
架構設計模型典型的有演變傳遞生命周期模型。該模型中，架構設計有少量關鍵需求就可以開始着手開始，把架構作為骨架，在骨架上循環疊代，逐漸長出有血有肉的系統之軀。其中屬性驅動設計法就是一種定義架構的方法。按照品質屬性來劃分子產品。
子產品分解完成後，就可以配置設定給各開發小組。此謂按架構組織開發團隊。
六、軟體架構文檔化
記錄軟體架構即編寫架構文檔。一方面，編寫過程促使架構師進一步思考，文檔編寫過程就是整理思路的過程；另一方面，文檔是架構開發的成果，供項目關系人使用：
程式員希望從中獲得限制和許可範圍；測試和內建人員從中得到測試黑箱；項目經理則據此獲得工作任務，組建開發小組，規劃和配置設定資源。
UML是編寫架構文檔事實上的标準表示法。
七、軟體架構評估
（一）評估方法
1、調查問卷
2、基于場景
通過分析軟體架構對場景的支援程度，進而判斷該架構對品質需求的滿足程度。有
架構權衡分析法
軟體架構分析法
3、基于度量
（二）架構的權衡分析法
從技術角度對軟體架構進行評估，通過分析來預見軟體的品質，建立、選擇、評估與比較不同的架構。
（三）成本效益分析法
成本效益分析法是在架構權衡分析法基礎上建構，用來對架構設計決策的成本和收益進行模組化，是優化此類決策的一種手段。其思想就是架構政策影響系統的品質屬性，反過來這些品質屬性又會帶來收益。