本篇博文目錄:

• • • 考點分析
    • 一.軟件架構(gòu)風(fēng)格
    • • 1.基本概念
      • 2.真題案例分析
    • 二.質(zhì)量屬性與架構(gòu)評估
    • • 1.基本概念
      • 2.案例分析
    • 三.Web架構(gòu)綜合考查
    • • 1.Web服務(wù)器技術(shù)演變
      • • (1) 負(fù)載均衡技術(shù)
        • (2) 持久化技術(shù)-ORM
        • (3) 數(shù)據(jù)庫讀寫分離
      • 2.緩存技術(shù)
      • 3.Redis技術(shù)
      • 4.CDN(內(nèi)容分發(fā)網(wǎng)絡(luò))
      • 5.XML與JSON
      • 6.Web應(yīng)用服務(wù)器
      • 7.REST
      • 8.響應(yīng)式Web設(shè)計
      • 9.中臺技術(shù)

考點分析

架構(gòu)設(shè)計在案例分析題中每年必考的知識點,主要考點如下:

一.軟件架構(gòu)風(fēng)格

1.基本概念

• 什么是架構(gòu)風(fēng)格

軟件架構(gòu)風(fēng)格是指描述特定軟件系統(tǒng)組織方式的慣用模式。組織方式描述了系統(tǒng)的組成構(gòu)件和這些構(gòu)件的組織方式，慣用模式則反映眾多系統(tǒng)共有的結(jié)構(gòu)和語義。

• 常用架構(gòu)風(fēng)格(需要能夠從題目中分析出來使用了什么架構(gòu)風(fēng)格)

架構(gòu)風(fēng)格種類

數(shù)據(jù)流風(fēng)格	批處理序列,管道過濾器
調(diào)用/返回風(fēng)格	主程序/子程序,面向?qū)ο?層次結(jié)構(gòu)
獨立構(gòu)件風(fēng)格	進(jìn)程通信,事件驅(qū)動系統(tǒng)
虛擬機(jī)風(fēng)格	解釋器
倉庫風(fēng)格	數(shù)據(jù)庫系統(tǒng),黑板系統(tǒng),超文本系統(tǒng)
其他風(fēng)格	消息總線/面向服務(wù)架構(gòu),過程控制,C2

具體架構(gòu)風(fēng)格的解釋:

架構(gòu)風(fēng)格描述

批處理序列	構(gòu)件為一系列固定順序的計算單元，構(gòu)件之間只通過數(shù)據(jù)傳遞交互。每個處理步驟是一個獨立的程序，每一步必須在其前一步結(jié)束后才能開始，數(shù)據(jù)必須是完整的，以整體的方式傳遞。傳統(tǒng)編譯器就是采用此種架構(gòu)風(fēng)格 。
管道-過濾器	每個構(gòu)件都有一組輸入和輸出，構(gòu)件讀輸入的數(shù)據(jù)流，經(jīng)過內(nèi)部處理，然后產(chǎn)生輸出數(shù)據(jù)流。這個過程通常是通過對輸入數(shù)據(jù)流的變換或計算來完成的，包括通過計算和增加信息以豐富數(shù)據(jù)、通過濃縮和刪除以精簡數(shù)據(jù)、通過改變記錄方式以轉(zhuǎn)化數(shù)據(jù)和遞增地轉(zhuǎn)化數(shù)據(jù)等。這里的構(gòu)件稱為過濾器，連接件就是數(shù)據(jù)流傳輸?shù)墓艿?#xff0c;將一個過濾器的輸出傳到另一個過濾器的輸入。
主程序/子程序	單線程控制，把問題劃分為若千個處理步驟，構(gòu)件即為主程序和子程序，子程序通常可合成為模塊。過程調(diào)用作為交互機(jī)制，即充當(dāng)連接件的角色。調(diào)用關(guān)系具有層次性，其語義邏輯表現(xiàn)為主程序的正確性取決于它調(diào)用的子程序的正確性
面向?qū)ο?/td>	構(gòu)件是對象，對象是抽象數(shù)據(jù)類型的實例。在抽象數(shù)據(jù)類型中，數(shù)據(jù)的表示和它們的相應(yīng)操作被封裝起來，對象的行為體現(xiàn)在其接受和請求的動作。連接件即是對象間交互的方式，對象是通過函數(shù)和過程的調(diào)用來交互的
層次結(jié)構(gòu)	構(gòu)件組織成一個層次結(jié)構(gòu)，連接件通過決定層間如何交互的協(xié)議來定義。每層為上一層提供服務(wù)，使用下一層的服務(wù)，只能見到與自己鄰接的層。通過層次結(jié)構(gòu)，可以將大的問題分解為若干個漸進(jìn)的小問題逐步解決，可以隱藏問題的復(fù)雜度。修改某一層，最多影響其相鄰的兩層(通常只能影響上層)
進(jìn)程通信	構(gòu)件是獨立的過程，連接件是消息傳遞。構(gòu)件通常是命名過程，消息傳遞的方式可以是點對點、異步或同步方式，以及遠(yuǎn)程過程(方法）調(diào)用等。
時間驅(qū)動系統(tǒng)(隱式調(diào)用)	構(gòu)件不直接調(diào)用一個過程，而是觸發(fā)或廣播一個或多個事件。構(gòu)件中的過程在一個或多個事件中注冊，當(dāng)某個事件被觸發(fā)時，系統(tǒng)自動調(diào)用在這個事件中注冊的所有過程。一個事件的觸發(fā)就導(dǎo)致了另一個模塊中的過程調(diào)用。這種風(fēng)格中的構(gòu)件是匿名的過程，它們之間交互的連接件往往是以過程之間的隱式調(diào)用來實現(xiàn)的。主要優(yōu)點是為軟件復(fù)用提供了強(qiáng)大的支持，為構(gòu)件的維護(hù)和演化帶來了方便;其缺點是構(gòu)件放棄了對系統(tǒng)計算的控制。
解釋器	解釋器通常包括一個完成解釋工作的解釋引擎、一個包含將被解釋的代碼的存儲區(qū)、一個記錄解釋引擎當(dāng)前工作狀態(tài)的數(shù)據(jù)結(jié)構(gòu)，以及一個記錄源代碼被解釋執(zhí)行的進(jìn)度的數(shù)據(jù)結(jié)構(gòu)。具有解釋器風(fēng)格的軟件中含有一個虛擬機(jī)，可以仿真硬件的執(zhí)行過程和一些關(guān)鍵應(yīng)用，其缺點是執(zhí)行效率比較低。
基于規(guī)則的系統(tǒng)	基于規(guī)則的系統(tǒng)包括規(guī)則集、規(guī)則解釋器、規(guī)則/數(shù)據(jù)選擇器和工作內(nèi)存，一般用在人工智能領(lǐng)域和DSS中。
黑板系統(tǒng)	包括知識源、黑板和控制三部分。知識源包括若干獨立計算的不同單元，提供解決問題的知識。知識源響應(yīng)黑板的變化，也只修改黑板﹔黑板是一個全局?jǐn)?shù)據(jù)庫，包含問題域解空間的全部狀態(tài)，是知識源相互作用的唯一媒介;知識源響應(yīng)是通過黑板狀態(tài)的變化來控制的。黑板系統(tǒng)通常應(yīng)用在對于解決問題沒有確定性算法的軟件中(信號處理、問題規(guī)劃和編譯器優(yōu)化等)。
超文本系統(tǒng)	構(gòu)件以網(wǎng)狀鏈接方式相互連接，用戶可以在構(gòu)件之間進(jìn)行按照人類的聯(lián)想思維方式任意跳轉(zhuǎn)到相關(guān)構(gòu)件。超文本是一種非線性的網(wǎng)狀信息組織方法，它以結(jié)點為基本單位，鏈作為結(jié)點之間的聯(lián)想式關(guān)聯(lián)。超文本系統(tǒng)通常應(yīng)用在互聯(lián)網(wǎng)領(lǐng)域。

2.真題案例分析

案例題練習(xí):

案例問題:

案例問題1參考答案:

從集成開發(fā)環(huán)境與用戶交互方式,集成開發(fā)環(huán)境的擴(kuò)展性,集成開發(fā)環(huán)境的數(shù)據(jù)管理三個方面進(jìn)行分析,為什么采用李工的方案。文中提到采用了李工的方案,說明李工在這三個方面上來說至少有二個方面的性能上要優(yōu)于王工,并且優(yōu)于的方面正好是系統(tǒng)需要的,從系統(tǒng)核心需求進(jìn)行分析,核心需求(1)適合采用以數(shù)據(jù)存儲為中心的架構(gòu)風(fēng)格,核心需求(2)適合采用解釋器風(fēng)格,核心需求(3)適合采用隱式調(diào)用的風(fēng)格。所以在問答這個問題的時候我們可以結(jié)合系統(tǒng)核心需求(1)進(jìn)行作答。核心需求(1)中用戶通常采用交互式的方式對腳本進(jìn)行編輯,語法檢測,解釋執(zhí)行和調(diào)試。說明以數(shù)據(jù)為中心的架構(gòu)風(fēng)格在交互方式上要優(yōu)于管道過濾器才行。并要實現(xiàn)各種功能的靈活組合、配置與替換。說明系統(tǒng)需要較好的可擴(kuò)展性,所以以數(shù)據(jù)為中心的架構(gòu)風(fēng)格在可擴(kuò)展性上需要優(yōu)于管道過濾器。最后從集成開發(fā)環(huán)境的數(shù)據(jù)管理方面來看,可以從數(shù)據(jù)類型和數(shù)據(jù)轉(zhuǎn)換的角度進(jìn)行作答,數(shù)據(jù)類型從核心需求1中可知系統(tǒng)需要支持腳本語言,語法樹(用于檢測語法錯誤)的數(shù)據(jù)類型,核心需求2可知系統(tǒng)需要支持可視化模型的數(shù)據(jù)類型,核心需求3可知系統(tǒng)需要支持調(diào)試信息的數(shù)據(jù)類型,從數(shù)據(jù)類型的轉(zhuǎn)換上來看,既然存在這么多種數(shù)據(jù)類型,肯定需要支持?jǐn)?shù)據(jù)類型的轉(zhuǎn)換才行。所以以數(shù)據(jù)為中心的軟件架構(gòu)風(fēng)格在數(shù)據(jù)管理方面需要優(yōu)于管道過濾器。

案例問題2參考答案:

這道題考查的就是從題目中分析出來使用了什么架構(gòu)風(fēng)格,解釋器風(fēng)格重點在于能夠自動生成新的環(huán)境(拖到控件生成新的界面代碼,是在自動生成新的環(huán)境),隱式調(diào)用風(fēng)格重點在于當(dāng)某個事件被觸發(fā)后調(diào)用某個方法(自動定位是當(dāng)觸發(fā)斷點在調(diào)試過程中命中這一事件，后執(zhí)行定位方法進(jìn)行定位操作)。

二.質(zhì)量屬性與架構(gòu)評估

1.基本概念

質(zhì)量屬性主要考查四種質(zhì)量屬性性能,可用性,安全性和可修改性(潛在的考試bug),并且能夠從文中分析出是哪一個質(zhì)量屬性。

概念部分主要考查的是風(fēng)險點,敏感點,權(quán)衡點的概念:
系統(tǒng)架構(gòu)風(fēng)險: 是指架構(gòu)設(shè)計中潛在的、存在問題的架構(gòu)決策所帶來的隱患。
敏感點: 是指為了實現(xiàn)某種特定的質(zhì)量屬性，一個或多個構(gòu)件所具有的特性。
權(quán)衡點: 是影響多個質(zhì)量屬性的特性，是多個質(zhì)量屬性的敏感點。

2.案例分析

下面給出屬性效用樹，需要在效用后面填入質(zhì)量屬性,在質(zhì)量屬性后面填入屬于該質(zhì)量屬性的題干。(1)和(2)需要填入質(zhì)量屬性,我們前面提到質(zhì)量屬性主要考查性能,可用性,可修改性和安全性,所以我們可以利用這個bug可知(1)和(2)里面有一個是可修改性有一個是可用性,具體哪一個是，我們根據(jù)后面給出的題干進(jìn)行分析,比如(1)后面給出的題干是e,題干e描述是 “需要在20人月內(nèi)為系統(tǒng)添加一個新的CORBA中間件” 主要描述的是可修改性，所以(1)為可修改性,(2)為可用性,為了進(jìn)一步驗證我們可以分析一下d題干,“網(wǎng)絡(luò)失效后，系統(tǒng)需要在1.5分鐘內(nèi)發(fā)現(xiàn)錯誤并啟用備用系統(tǒng);” 這明顯是對可用性的描述，所以(1)為可修改性,(2)為可用性。(3) ~ (6) 需要對題干進(jìn)行分析填入符合條件的質(zhì)量屬性的題干即可。

對題干進(jìn)行分析后相關(guān)質(zhì)量屬性和風(fēng)險點,非風(fēng)險點，權(quán)衡點和敏感點的分析如下:

題2三個概念的描述如下:

三.Web架構(gòu)綜合考查

Web開發(fā)設(shè)計技術(shù)的綜合應(yīng)用主要圍繞高性能,高可用,可維護(hù),應(yīng)變,安全等屬性展開。

從不同維度來看Web系統(tǒng)架構(gòu)所設(shè)計技術(shù)內(nèi)容，如下:

Web系統(tǒng)的分層如系統(tǒng)所示:

1.Web服務(wù)器技術(shù)演變

單體機(jī)器，web應(yīng)用和數(shù)據(jù)庫存放在一臺機(jī)器上,存在安全隱患，因為web應(yīng)用暴露在外,供用戶使用,數(shù)據(jù)庫存儲用戶數(shù)據(jù),應(yīng)該避免這種暴露行為,并且web應(yīng)用和數(shù)據(jù)庫都比較消耗資源,當(dāng)用戶量大了,開銷大了,單臺機(jī)器可能承載不了這種開銷造成宕機(jī)，所以將數(shù)據(jù)庫與web服務(wù)器進(jìn)行分離,將web應(yīng)用服務(wù)器放在一臺機(jī)器上,數(shù)據(jù)庫服務(wù)器放在另外一臺機(jī)器上,就算web應(yīng)用蹦了也不會影響數(shù)據(jù)庫服務(wù)器,且這種方式避免了數(shù)據(jù)庫暴露在外。

當(dāng)數(shù)據(jù)量非常大的時候,高并發(fā)場景下容易造成單點故障,可以通過搭建應(yīng)用服務(wù)器集群的方式提供不同的應(yīng)用服務(wù)器供用戶使用,就算單臺應(yīng)用服務(wù)器蹦了,可以通過更換不同的應(yīng)用服務(wù)器來供用戶訪問,避免單點故障。

在應(yīng)用服務(wù)器集群中我們需要考慮以下二個問題

(1) 負(fù)載均衡技術(shù)

問題1主要通過負(fù)載均衡技術(shù)來解決用戶請求轉(zhuǎn)發(fā)的工作,負(fù)載均衡主要從應(yīng)用層和傳輸層的角度進(jìn)行實現(xiàn)。

負(fù)載均衡技術(shù),從應(yīng)用層角度進(jìn)行實現(xiàn)分為基于特定軟件的負(fù)載均衡(HTTP重定向)和反向大力負(fù)載均衡。

負(fù)載均衡技術(shù),從傳輸層角度進(jìn)行實現(xiàn)分為DNS域名解析的負(fù)載均衡和基于NAT的負(fù)載均衡。相比于應(yīng)用層角度的負(fù)載均衡傳輸層負(fù)載均衡的性能更優(yōu)。

下圖給出的是負(fù)載均衡技術(shù)相應(yīng)算法,上面講解的負(fù)載均衡是實現(xiàn)方式,而算法是如何分配的問題,會按照相應(yīng)算法策略去實現(xiàn)用戶自動的,智能的分配應(yīng)用服務(wù)器。

傳統(tǒng)的情況下,應(yīng)用服務(wù)器只有一臺,用戶進(jìn)行登入后會將session寫入到應(yīng)用服務(wù)器中,這樣避免了用戶每訪問一個頁面就需要用戶端提供用戶信息,因為session中存放了用戶的數(shù)據(jù),由于采用了應(yīng)用服務(wù)器的集群,如果還是傳統(tǒng)的方式的話,用戶在應(yīng)用服務(wù)器1中登入后保存了session信息,但是當(dāng)用戶訪問應(yīng)用服務(wù)器2時這個信息就沒有了,應(yīng)用服務(wù)器就不知道用戶已經(jīng)進(jìn)行了登入操作，就無法進(jìn)行相關(guān)應(yīng)用服務(wù)的訪問和使用。所以為了解決這個問題提供了三種解決方案,方案1攜帶session的cookie,方案2服務(wù)器間同步session,方案3將session存入redis。這里的cookie是一種身份認(rèn)證,比如用戶1連接了應(yīng)用服務(wù)器,用戶2連接了應(yīng)用服務(wù)器,應(yīng)用服務(wù)器怎么知道哪一個是用戶1和用戶2呢,就可以通過用戶發(fā)來的cookie進(jìn)行識別,比如cookie里面存放userid=1,發(fā)送到應(yīng)用服務(wù)器,服務(wù)器通過cookie中的userid=1就可以知道原來是用戶1發(fā)來的請求,當(dāng)發(fā)來的cookie的userid=2時就會知道是用戶2發(fā)來的請求。

無狀態(tài)服務(wù)和有狀態(tài)服務(wù),所謂的有狀態(tài)服務(wù)就是服務(wù)請求會攜帶數(shù)據(jù)保存到服務(wù)器中幫助下一次服務(wù)使用，無狀態(tài)不用保存數(shù)據(jù)到服務(wù)器中，這次服務(wù)完后對后面的服務(wù)沒有任何影響。

(2) 持久化技術(shù)-ORM

持久化技術(shù)ORM是在JDBC接口基礎(chǔ)上進(jìn)行封裝的一層框架,幫助程序員更容易操作數(shù)據(jù),提高程序的易用性，常用的ORM框架有Hibernate和MyBatis。

(3) 數(shù)據(jù)庫讀寫分離

數(shù)據(jù)讀寫分離的意思就是將數(shù)據(jù)庫的讀和寫操作(增,刪,改)分開,放在不同的數(shù)據(jù)庫服務(wù)器上,其中寫操作為主庫,讀操作為從庫,主庫和從庫之間通過日志實現(xiàn)數(shù)據(jù)同步。沒有讀寫分離時，大量的查詢與對表增加排它鎖，從而影響其他操作，所以可以通過讀寫分離進(jìn)行避免。

2.緩存技術(shù)

對查多寫(增,刪,改)少的場景我們可以考慮使用數(shù)據(jù)緩存技術(shù),減少數(shù)據(jù)庫服務(wù)器的開銷，當(dāng)用戶進(jìn)行查詢時,首先查詢緩存中是否存在數(shù)據(jù),如果存在就從緩存中取值,如果緩存中沒有數(shù)據(jù)就從數(shù)據(jù)庫中取值,并且更新數(shù)據(jù)到緩存中,如果用戶對數(shù)據(jù)進(jìn)行修改，數(shù)據(jù)庫中的數(shù)據(jù)進(jìn)行更新并且更新緩存中的數(shù)據(jù)保持?jǐn)?shù)據(jù)的一致性。

緩存的數(shù)據(jù)常常采用key-value的形式進(jìn)行存儲,常用的緩存框架有Memcache和Redis。

Memcache和Redis的區(qū)別需要了解,如下圖所示:

3.Redis技術(shù)

4.CDN(內(nèi)容分發(fā)網(wǎng)絡(luò))

內(nèi)容分發(fā)網(wǎng)絡(luò)中的CDN類似于現(xiàn)實生活中的快遞場景,用戶不直接連接數(shù)據(jù)源站點而是連接離自己家最近的CDN站點,這里的CDN站點類似于快遞取件點(菜鳥驛站),通過這樣的方式可以使內(nèi)容傳輸?shù)酶?#xff0c;更穩(wěn)定。

5.XML與JSON

XML和JSON是二種比較傳統(tǒng)的網(wǎng)絡(luò)交互方式,其中XML方式通過標(biāo)簽的方式描述數(shù)據(jù),XML方式的優(yōu)缺點如下圖所示:

JSON是一種輕量級的數(shù)據(jù)交互格式,具有良好的可讀和便于快速編寫的特性，可以在不同平臺進(jìn)行數(shù)據(jù)交互。,優(yōu)缺點如下所示:

6.Web應(yīng)用服務(wù)器

7.REST

REST表述性狀態(tài)轉(zhuǎn)移是數(shù)據(jù)交換形式,對資源標(biāo)準(zhǔn)化的過程,把資源的操作更加規(guī)范化，如
http://www.educity.cn/orders/29127123134 網(wǎng)址就是通過REST進(jìn)行了規(guī)范化,從網(wǎng)址我們能夠猜測這是一個關(guān)于29127123134訂單信息的處理，通過REST進(jìn)行規(guī)范化后,結(jié)構(gòu)非常清晰,便于理解,可以降低開發(fā)的復(fù)雜性,提高系統(tǒng)的可升縮性。我們在Web開發(fā)中也遵循該風(fēng)格,也就是我們常說的Rest ful Api風(fēng)格。

8.響應(yīng)式Web設(shè)計

響應(yīng)式Web設(shè)計就是網(wǎng)站對于不同設(shè)備的適配問題，我們可以采用流式布局和彈性化設(shè)計，就是使用相對單位通過設(shè)置百分比的方式表示圖片的長寬。也可以采用響應(yīng)式圖片的方式,對圖片同比縮放，并降低圖片自身的分辨率。

9.中臺技術(shù)

總結(jié)

以上是生活随笔為你收集整理的软考高级-系统架构师-案例分析-架构设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。