目錄
- 軟考官網 報名通道
- 軟考架構師筆記（一）：計算機系統基礎
- 軟考架構師筆記（二）：計算機網絡基礎與信息安全
- 軟考架構師筆記（三）：操作系統基礎
- 軟考架構師筆記（四）：企業信息化與系統規划
- 軟考架構師筆記（五）：系統需求工程 需求分析
- 軟考架構師筆記（六）：數據庫
- 軟考架構師筆記（七）：系統分析 系統設計
- 軟考架構師筆記（八）：系統架構 架構設計
- 軟考架構師筆記（九）：軟件工程與項目管理
- 軟考架構師筆記（十）：系統測試 維護 穩定性
目錄
軟件架構概念
軟件架構風格是描述某一特定應用領域中系統組織方式的慣用模式。
架構風格定義一個系統家族，即一個體系結構定義一個詞匯表和一組約束。詞匯表中包含一些構件和連接件類型，而這組約束指出系統是如何將這些構件和連接件組合起來的。
軟件架構為軟件系統提供了一個結構、行為和屬性的高級抽象，由構成系統的元素的描述、這些元素的相互作用、指導元素集成的模式以及這些模式的約束組成。
軟件架構是項目干系人進行交流的手段，明確了對系統實現的約束條件，決定了開發和維護組織的組織結構，制約着系統的質量屬性
軟件架構使推理和控制的更改更加簡單，有助於循序漸進的原型設計，可以作為培訓的基礎
軟件架構是可傳遞和可復用的模型，通過研究軟件架構可能預測軟件的質量
軟件架構建模
結構模型：以架構的構件、連接件和其他概念來刻畫結構
框架模型：不太側重描述結構的細節而更側重於整體的結構
動態模型：系統的“大顆粒”的行為性質
過程模型：構建系統的步驟和過程
功能模型：由一組功能構件按層次組成，下層向上層提供服務
RUP 4+1
用例視圖（Use Cases View），最初稱為場景視圖，關注最終用戶需求，為整個技術架構的上線文環境.通常用UML用例圖和活動圖描述。
邏輯視圖（Logical view），主要是整個系統的抽象結構表述，關注系統提供最終用戶的功能，不涉及具體的編譯即輸出和部署，通常在UML中用類圖，交互圖，時序圖來表述，類似與我們采用OOA的對象模型。
開發視圖(Development View)，描述軟件在開發環境下的靜態組織，從程序實現人員的角度透視系統，也叫做實現視圖(implementation view)。開發視圖關注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現成框架、類庫，以及開發的系統將運行於其上的系統軟件或中間件, 在UML中用組件圖，包圖來表述。開發視圖和邏輯視圖之間可能存在一定的映射關系：比如邏輯層一般會映射到多個程序包等。
物理視圖（Physical view ）物理視圖通常也叫做部署視圖(deploymentview)，是從系統工程師解讀系統，關注軟件的物流拓撲結，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性等要求。物理視圖和處理視圖的關系：處理視圖特別關注目標程序的動態執行情況，而物理視圖重視目標程序的靜態位置問題；物理視圖是綜合考慮軟件系統和整個IT系統相互影響的架構視圖。
處理視圖（Process view）(進程視圖) 處理視圖關注系統動態運行時，主要是進程以及相關的並發、同步、通信等問題。處理視圖和開發視圖的關系：開發視圖一般偏重程序包在編譯時期的靜態依賴關系，而這些程序運行起來之后會表現為對象、線程、進程，處理視圖比較關注的正是這些運行時單元的交互問題，在UML中通常用活動圖表述。
軟件架構風格
架構設計的一個核心問題是能否達到架構級的軟件復用
架構風格反映了領域中眾多系統所共有的結構和語義特性，並指導如何將各個構件有效地組織成一個完整的系統
架構風格定義了用於描述系統的術語表和一組指導構建系統的規則
Garlan和Shaw對通用軟件架構風格進行了分類，他們將軟件架構分為數據流風格、調用/返回風格、獨立構件風格、虛擬機風格和倉庫風格。
（1）數據流風格：數據流風格包括批處理序列和管道/過濾器兩種風格。
（2）調用/返回風格：調用/返回風格包括主程序和子程序、數據抽象和面向對象，以及層次結構。
（3）獨立構件風格：獨立構件風格包括進程通信和事件驅動的系統。
（4）虛擬機風格：虛擬機風格包括解釋器和基於規則的系統。
（5）倉庫風格：倉庫風格包括數據庫系統、黑板系統和超文本系統。
（6）過程控制：閉環控制
倉庫風格中構件分兩種：
- 一種是中央數據結構，保存系統的當前狀態；
- 另一種是獨立構件，對中央數據存儲進行操作。
黑板系統：
黑板（共享數據）,知識源 , 控制
知識源包括若干獨立計算的不同單元，提供解決問題的知識。知識源響應黑板的變化，也只修改黑板；黑板是一個全局數據庫，包含問題域解空間的全部狀態，是知識源相互作用的唯一媒介；知識源響應是通過黑板狀態的變化來控制的。黑板系統通常應用在對於解決問題沒有確定性算法的軟件中（信號處理、問題規划和編譯器優化，語音識別等）。
超文本：
構件以網狀鏈接方式相互連接，用戶可以在構件之間進行按照人類的聯想思維方式任意跳轉到相關構件。超文本是一種非線性的網狀信息組織方法，它以結點為基本單位，鏈作為結點之間的聯想式關聯。超文本系統通常應用在互聯網領域。
層次架構風格
- CS架構：架構是客戶端和服務器架構，通過充分利用兩端硬件環境的優勢，將任務合理分配到Client端和Server端來實現。
- BS架構：架構是瀏覽器和服務器架構，用戶工作界面是通過瀏覽器來實現，極少部分事務邏輯在前端（Browser）實現，但是主要事務邏輯在服務器端（Server）實現。
富互聯網 RIA
HTML5， AJAX，Laszlo，Bindows，FLex，JAVA
RIA結合了C/S架構反應速度快、交互性強的優點，以及B/S架構傳播范圍廣及容易傳播的特性
RIA簡化並改進了B/S架構的用戶交互
數據能夠被緩存在客戶端，從而可以實現一個比基於HTML的響應速度更快且數據往返於服務器的次數更少的用戶界面
基於服務的架構 SOA
面向服務的架構（Service-Oriented Architecture，SOA）是透過業務服務的概念來提供IT的各項基本應用功能，讓這些服務可以自由地被排列組合，融會貫通，以便在未來能隨時彈性配合新的需求而調整。
SOA架構只是實現和解決了服務模塊間調用的互操作問題，為了更好地服務於企業應用，引入了企業服務總線（ESB）的應用架構。這一構架是基於消息中間件（Messaging Middleware）、智能路由和數據轉換等技術實現的。
SOA的實現方式：ESB 服務總線 各種服務掛到總線上，依賴總線 完成互聯互通
充當中介者角色，對接各個服務; 例如Webservice 封裝遺留系統為單個服務；
特點：
松散耦合，粗粒度，標准化接口；
ESB提供了一個基於標准的松散應用耦合模式，
ESB由以下3層構成：
總線接入層：通過這一層可以使用戶的各種應用接入ESB，使用ESB的各種服務。在這一層提供對多種主流應用的接入協議支持，如HTTP、JCA/J2C、NET和IBM/CICS等。同時考慮到一些客戶自己定制的應用與ESB的連接，在總線接入層提供了適配器服務。
核心層：提供多種企業服務總線所需的必要服務支持，在這一層除了提供總線基本服務（如分發/訂閱、隊列、安全服務和仲裁服務等）外，還提供了QoS的支持（如高可用性、確保消息傳輸等）。微流程組合/拆分或定制
路由層：這一層是側重在業務支持上。通過通用和標准的對象、服務模型，可以在這一層上定義可重用和基於業界標准的業務流程。
關鍵技術
WSDL：
WSDL就是WebService接口對應的WSDL文件，該文件通過xml格式說明如何調用，可以看作WebService的接口文檔（使用說明書）。
服務實現定義： 服務和端口
服務接口定義：綁定，端口類型，消息，類型
SOAP：
SOAP，Simple Object Access Protocol，簡單對象訪問協議，簡單的說就是用於訪問網絡服務的協議；它是基於XML的簡易協議，可使應用程序在HTTP之上進行信息交換。
SOAP是一種網絡通信協議，用於網絡上、不同平台、不同語言的應用程序間的通訊。 HTTP協議+XML數據格式
SO方法的服務建模：按照實施的階段，服務建模可以分為服務發現、服務規約和服務實現三個階段。
（1）服務發現。采用自上而下、自下而上和中間對齊的方式，得到候選服務。
（2）服務規約。對候選服務進行分類，根據是否便於復用和組裝，是否具有業務對齊性來決定是否將服務暴露。同時，需要考慮服務的信息系統特性。服務規約還包括服務編排、服務庫和服務總線中間件模式的設計等過程。
（3）服務實現。根據對業務領域的理解和現有系統的分析，將服務的實現分配到相應的服務構件中，並決定服務的實現方式。具體的實現方式既可以由現有系統暴露相關功能為服務，或者重新開發相關功能提供務，也可以由合作伙伴來提供服務。無論采用哪種方式，系統分析師都需要對於關鍵點進行技術可行性分析。
MDA
架構描述語言ADL
ADL是一種形式化語言，它在底層語義模型的支持下，為軟件系統的概念體系結構建模提供了具體語法和概念框架。基於底層語義的工具為體系結構的表示、分析、演化、細化、設計過程等提供支持。
ADL的三個基本元素
構件：計算或數據存儲單元；
連接件：用於構件之間交互建模的體系結構構造塊及其支配這些交互的規則；
架構配置：描述體系結構的構件與連接件的連接圖
特定領域軟件架構 DSSA
基於架構的軟件開發 ABSD
ABSD方法是架構驅動，即強調由業務、質量和功能需求的組合驅動架構設計。
使用ABSD方法，設計活動可以從項目總體功能框架明確就開始，這意味着需求獲取和分析還沒有完成（甚至遠遠沒有完成），就開始了軟件設計。
ABSD方法有三個基礎。
第一個基礎是功能的分解。在功能分解中，ABSD方法使用已有的基於模塊的內聚和耦合技術；
第二個基礎是通過選擇架構風格來實現質量和業務需求；
第三個基礎是軟件模板的使用。軟件模板利用了一些軟件系統的結構。
ABSD方法是遞歸的，且迭代的每一個步驟都是清晰地定義的。因此，不管設計是否完成，架構總是清晰的，這有助於降低架構設計的隨意性。
視角與視圖：從不同的視角來檢查，所以會有不同的視圖。
用例用來捕獲功能需求、特定場景來捕獲質量需求。
開發過程
軟件質量屬性
軟件建構評估
中間件技術
中間件是一種獨立的系統軟件或服務程序，可以幫助分布式應用軟件在不同的技術之間共享資源;
它具有規范的接口規約和顯式的語境依賴。軟件構件可以被獨立地部署並由第三方任意地組裝。
- 負責客戶機與服務器之間的連接和通信，以及客戶機與應用層之間的高效率通信機制
- 提供應用層不同服務之間的互操作機制，以及應用層與數據庫之間的連接和控制機制
- 提供多層架構的應用開發和運行的平台，以及應用開發框架，支持模塊化的應用開發
- 屏藏硬件、操作系統、網縮和數據庫的差異
- 提供應用的負載均衡和離可用性、安全機制與管理功能，以及交易管理機制，保證交易的一致性
- 提供一組通用的服務去執行不同的功能，避免重復的工作和使應用之間可以協作
Web架構設計
主要涉及：
從架構來看：MVC，MVP，MWM，REST，Webservice，微服務，中台。
從緩存來看：MemCache，Redis，Squid。
從並發分流來看：集群（負載均衡）、CDN。
從數據庫來看：主從庫（主從復制），內存數據庫，反規范化技術，NosQL，分區（分表）技術，視圖與物化視圖。
從持久化來看：Hibernate，Mybatis。
從分布存儲來看：Hadoop，FastDFS，區塊鏈。
從數據編碼看：XML，JSON。
從Web應用服務器來看：Apache，WebSphere，Weblogic，Tomcat，JBOSS，IS。
其它：靜態化，有狀態與無狀態，響應式Web設計。
負載均衡問題
典型應用架構
- J2EE 分布式多層應用程序
- .NET
- MVC/MVP設計模式
MVC模式，即模型一視圖一控制（Model-View-Controller）模式，它實際上是一種架構模式，是為那些需要為同樣的數據提供多個視圖的應用程序而設計的，它很好地體現了數據層與表示層的分離。
MCV把應用程序分為3種對象類型。
模型：應用問題域中包含的抽象領域知識；
視圖：將應用問題域中包含的抽象領域知識呈現給用戶的方法：一個模型可以用於多個視圖；
控制器：用戶界面對用戶輸入的響應方式。 - Web系統架構
負載均衡：
基於特定軟件的負載均衡（HTTP重定向）（應用層）
反向代理負載均衡（應用層）
基於DNS的負載均衡（傳輸層）
基於NAT的負載均衡（傳輸層）
混合型負載均衡
靜態算法：輪轉算法、加權輪轉算法、源地址哈希散列算法、目標地址哈希散列算法、隨機算法
動態算法：最小連接數算法、加權最小連接數算法、加權百分比算法 - 面向消息中間件（Message-Oriented Middleware，MOM）：利用高效可靠的消息傳遞機制進行平台無關的數據傳遞，並可基於數據通信進行分布系統的集成。通過提供消息傳遞和消息隊列模型，可在分布環境下擴展進程間的通信，並支持多種通信協議、語言、應用程序、硬件和軟件平台。
- EJB EJB是企業級Java構件，用於開發和部署多層結構、分布式、面向對象的Java應用系統。
EJB分為會話Bean、實體Bean和消息驅動Bean。
（1）會話Bean：用於實現業務邏輯，它可以是有狀態的，也可以是無狀態的。每當客戶端請求時，容器就會選擇一個會話Bean來為客戶端服務。會話Bean可以直接訪問數據庫，但更多時候，它會通過實體Bean實現數據訪問。
（2）實體Bean：用於實現O/R映射，負責將數據庫中的表記錄映射為內存中的實體對象。事實上，創建一個實體Bean對象相當於新建一條記錄；刪除一個實體Bean會同時從數據庫中刪除對應記錄；修改一個實體Bean時，容器會自動將實體Bean的狀態和數據庫同步。
（3）消息驅動Bean:EJB3.0中引入的新的企業Bean，它基於JMS消息，只能接收客戶端發送的JMS消息后處理。MDB實際上是一個異步的無狀態會話Bean，客戶端調用MDB后無須等待，立刻返回，MDB將異步處理客戶請求。這適合於需要異步處理請求的場合，如訂單處理，這樣就能避免客戶端長時間地等待一個方法調用直到返回結果。 - CORBA服務端構件模型中，
（1）伺服對象（Servant）：CORBA對象的真正實現，負責完成客戶端請求。
（2）對象適配器（Object Adapter）：用於屏蔽ORB內核的實現細節，為服務器對象的實現者提供抽象接口，以便它們使用ORB內部的某些功能。
（3）對象請求代理（Object Request Broker）：解釋調用並負責查找實現該請求的對象，將參數傳給找到的對象，並調用方法返回結果。客戶方不需要了解服務對象的位置、通信方式、實現、激活或存儲機制。