基礎(chǔ)知識

UML 關(guān)系

用例之間的關(guān)系：包擴泛：包含（必須使用）、擴展（可能使用）、泛華（父子/特例）
類之間的關(guān)系：關(guān)實泛依（關(guān)十反一） ： 依賴、泛華、關(guān)聯(lián)、實現(xiàn)

SOA定義：

SOA是一個組件模型，它將應(yīng)用程序拆分為不同的功能單元（稱為服務(wù)）
通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來。
接口采用中立方式定義，獨立于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言。
使服務(wù)可以一種統(tǒng)一和通用方式進行交互。

SOA與微服務(wù)的區(qū)別

a、微服務(wù)相比于SOA更加精細，微服務(wù)更多的以獨立的進程的方式存在，互相之間并無影響；
b、微服務(wù)提供的接口方式更加通用化，例如HTTP RESTful方式，各種終端都可以調(diào)用，無關(guān)語言、平臺限制；
c、微服務(wù)更傾向于分布式去中心化的部署方式，在互聯(lián)網(wǎng)業(yè)務(wù)場景下更適合；

ESB的作用和特點：

1、總線作用：ESB在面向服務(wù)架構(gòu)中起到總線作用，將各種服務(wù)進行連接和整合；
2、元數(shù)據(jù)和注冊作用：描述服務(wù)的元數(shù)據(jù)和服務(wù)注冊管理；
3、數(shù)據(jù)傳遞和轉(zhuǎn)換作用：在服務(wù)請求者和提供者之間傳遞數(shù)據(jù)，以及對這些數(shù)據(jù)進行轉(zhuǎn)換的能力，并支持由實踐中總結(jié)出來的一些模式，如同步模式、異步模式等；
4、服務(wù)發(fā)現(xiàn)、路由作用：發(fā)現(xiàn)、路由、匹配和選擇的能力，以支持服務(wù)之間的動態(tài)交互，解耦服務(wù)請求者和服務(wù)提供者。高級一些能力，包括對安全的支持、服務(wù)質(zhì)量保證、可管理性和負載平衡等。

狀態(tài)圖和活動圖區(qū)別：

1、狀態(tài)圖主要用于描述一個對象在其生存期間的動態(tài)行為，表現(xiàn)一個對象所經(jīng)歷的狀態(tài)序列，引起狀態(tài)轉(zhuǎn)移的事件（event），以及因狀態(tài)轉(zhuǎn)移而伴隨的動作（action）。
2、活動圖可以用于描述系統(tǒng)的工作流程和并發(fā)行為。活動圖其實可看作狀態(tài)圖的特殊形式，活動圖中一個活動結(jié)束后將立即進入下一個活動（在狀態(tài)圖中狀態(tài)的轉(zhuǎn)移可能需要事件的觸發(fā)）。
3、兩者最大的區(qū)別是：狀態(tài)圖側(cè)重于描述行為的結(jié)果，而活動圖側(cè)重描述行為的動作。其次活動圖可描述并發(fā)行為，而狀態(tài)圖不能。

數(shù)據(jù)流圖 與 系統(tǒng)流程圖的區(qū)別：

a. 并行：數(shù)據(jù)流圖中的處理過程可并行，系統(tǒng)流程圖在某個時間點只能處于一個處理過程
b. 計時標準：數(shù)據(jù)流圖展現(xiàn)全局的處理過程，過程之間遵循不同的計時標準，系統(tǒng)流程圖中處理過程遵循致的計時標準。
c. 數(shù)據(jù)流：數(shù)據(jù)流圖展現(xiàn)系統(tǒng)的數(shù)據(jù)流;系統(tǒng)流程圖展現(xiàn)系統(tǒng)的控制流。

活動圖與系統(tǒng)流程圖的區(qū)別：

a. 活動圖描述的是對象活動的順序關(guān)系所遵循的規(guī)則，它著重表現(xiàn)系統(tǒng)的行為，而非處理過程，而流程圖著重描述處理過程。
b. 活動圖則可以支持并發(fā)進程，流程圖一般都限于順序進程
c. 活動圖是面向?qū)ο蟮?，而流程圖是面向過程的。

面向?qū)ο笈c基于規(guī)則的風(fēng)格的對比

a. 靈活性
面向?qū)ο螅簩⒂脩粢?guī)則、折扣規(guī)則封裝為對象，在系統(tǒng)啟動時加載
基于規(guī)則：在系統(tǒng)啟動時加載，并支持運行中動態(tài)更新，靈活性更好
b. 可擴展
面向?qū)ο螅阂?guī)則修改時，需要通過修改程序、添加類的方式 ，通過系統(tǒng)重啟、動態(tài)反射或動態(tài)加載，擴展性差
基于規(guī)則：規(guī)則增加時，只需要定義新的規(guī)則，解釋規(guī)則即可進行擴展
c.性能
面向?qū)ο螅阂?guī)則以硬編碼方式書寫，編譯后運行，性能好
基于規(guī)則：需要對規(guī)則進行實時解釋，性能較差

倉庫風(fēng)格與 管道過濾器風(fēng)格區(qū)別

a. 數(shù)據(jù)處理方便：
管道：數(shù)據(jù)驅(qū)動機制，處理流程事先確定，交互性差
倉庫：數(shù)據(jù)統(tǒng)一保存在中央數(shù)據(jù)倉庫，數(shù)據(jù)處理流程相對獨立，支持交互式處理
b. 可擴展性
管道：管道-過濾器風(fēng)格容易添加新的過濾器，可擴展性好。
倉庫：數(shù)據(jù)與處理解耦合，可動態(tài)添加和刪除處理組件
c. 處理性能
管道：優(yōu)勢: 支持過濾器并發(fā)調(diào)用，性能提高；劣勢:需要數(shù)據(jù)格式轉(zhuǎn)換，性能降低；
倉庫：優(yōu)勢: 倉庫風(fēng)格容錯性和健壯性好；劣勢:倉庫風(fēng)格不支持并行，效率低。

采用標準數(shù)據(jù)訪問機制的好處：

a. 標準的數(shù)據(jù)訪問機制提供了不同標準間的數(shù)據(jù)訪問機制，它屏蔽了不同通信協(xié)議之間的差異，為上層應(yīng)用程序提供統(tǒng)一的訪問接口，可以容易地實現(xiàn)應(yīng)用程序?qū)Σ煌偩€協(xié)議設(shè)備的互操作，使得開發(fā)人員從低層的開發(fā)中脫離出來。
b. 它獨立于平臺，確保來自多個廠商的設(shè)備之間的信息無縫傳輸，具有語言無關(guān)性代碼重用性、易于集成性等優(yōu)點。當硬件升級或修改時只需改動硬件接口部分即可，不會影響上層應(yīng)用程序。例如，工業(yè)自動化領(lǐng)域常用 OPC。

數(shù)據(jù)流圖和數(shù)據(jù)字典在需求和設(shè)計階段的作用

在需求分析階段：數(shù)據(jù)流圖過數(shù)據(jù)的輸入、流向、處理過程、輸出，可以清晰地反映出系線是完成的邏輯功能，從而可盡早發(fā)現(xiàn)是否有需要輸入或輸出的信息被遺漏，以及系統(tǒng)各部分的邏輯是否存在錯誤；數(shù)據(jù)字典是描述數(shù)據(jù)的信息集合，通過數(shù)據(jù)字典可使參與人員對模型中的元素有共同的理解。
在設(shè)計階段，根據(jù)數(shù)據(jù)流圖，通過變換分析和事務(wù)分析的方法，可設(shè)計出系統(tǒng)的模塊結(jié)構(gòu)(系統(tǒng)結(jié)構(gòu)圖)；根據(jù)數(shù)據(jù)字典中的數(shù)據(jù)存儲描述可建立數(shù)據(jù)庫存儲設(shè)讓

設(shè)計模式分為三類：創(chuàng)建型、結(jié)構(gòu)型、行為型

a. 創(chuàng)建型，關(guān)注的是對象的創(chuàng)建，創(chuàng)建型模式將創(chuàng)建對象的過程進行了封裝，作為客戶程序僅僅需要去使用對象，而不再關(guān)心創(chuàng)建對象過程中的邏輯
b. 結(jié)構(gòu)型，主要用于處理類或?qū)ο蟮慕M合，對類如何設(shè)計以形成更大的結(jié)構(gòu)提供指南。
c. 行為型，行為型模式重點關(guān)注類或?qū)ο笾g的相互作用，通過行為型模式，可以更加清晰地劃分類與對象的職責(zé)，并研究系統(tǒng)在運行時實例對象之間的交互。

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

架構(gòu)建模的4+1視圖

4+1視圖模型從5個視角來描述軟件架構(gòu)，分別為：邏輯視圖、物理視圖、進程視圖、開發(fā)視圖和場景視圖。邏輯視圖主要描述系統(tǒng)的功能需求，將系統(tǒng)分解為一系列的功能抽象，可用對象模型來代表，用類圖來描述；開發(fā)視圖主要側(cè)重于軟件模塊的組織和管理，考慮軟件內(nèi)部的需求；進程視圖側(cè)重于系統(tǒng)的運行特性，主要關(guān)注非功能需求，強調(diào)并發(fā)性、分布性、系統(tǒng)集成性和容錯能力，以及邏輯視圖中的功能抽象如何適應(yīng)進程結(jié)構(gòu)，定義了具體線程執(zhí)行的操作；物理視圖主要考慮軟件向硬件的映射，解決系統(tǒng)的拓撲結(jié)構(gòu)、安裝和通信問題。場景視圖可看做重要系統(tǒng)活動的抽象，使其他4個視圖有機聯(lián)系。
4+1 視圖的基本思想是關(guān)注點分離原則，通過一個統(tǒng)一的場景，把四個視圖有機的聯(lián)系起來，幫助軟件設(shè)計者架構(gòu)構(gòu)件和他們之間的關(guān)系。

基于架構(gòu)的軟件設(shè)計方法（ABSD）包括六個階段：架構(gòu)需求、架構(gòu)設(shè)計、架構(gòu)文檔化、架構(gòu)復(fù)審、架構(gòu)實現(xiàn)和架構(gòu)演化。

架構(gòu)需求階段，明確用戶對系統(tǒng)在功能、行為、性能、設(shè)計約束等方面的期望，包括需求獲取、標識構(gòu)件和需求評審；
架構(gòu)設(shè)計階段，根據(jù)需求生成并調(diào)整架構(gòu)決策，包括提出架構(gòu)模型、映射構(gòu)件、分析構(gòu)件相互作用、產(chǎn)生架構(gòu)和設(shè)計評審；設(shè)計評審之后可能還會重新對構(gòu)件映射做出調(diào)整，所以其中的活動也存在重復(fù)多次的情形；
架構(gòu)文檔化階段，對架構(gòu)設(shè)計階段的成果進行分析和整理后形成文檔，產(chǎn)生架構(gòu)規(guī)格說明書和質(zhì)量設(shè)計說明書；
架構(gòu)復(fù)審階段，評價架構(gòu)能否滿足需求與實現(xiàn)質(zhì)量屬性、層次構(gòu)件劃分是否合理，標識潛在的風(fēng)險，及早發(fā)現(xiàn)設(shè)計中的缺陷錯誤；
架構(gòu)實現(xiàn)階段，對架構(gòu)進行實現(xiàn)，包括架構(gòu)分析與設(shè)計、構(gòu)件實現(xiàn)、組裝和系統(tǒng)測試；
架構(gòu)演化階段，主要解決開發(fā)中用戶需求變更問題，包括架構(gòu)演化計劃、構(gòu)件變動、更新構(gòu)件相互作用、構(gòu)件組裝測試與技術(shù)評審。

基于架構(gòu)的軟件設(shè)計方法ABSD，是架構(gòu)驅(qū)動的，強調(diào)由商業(yè)，質(zhì)量和功能需求的組合驅(qū)動軟件架構(gòu)設(shè)計。強調(diào)用視角與視圖描述軟件架構(gòu)，用用例與質(zhì)量場景描述需求。

架構(gòu)評估的質(zhì)量屬性

架構(gòu)評估是軟件開發(fā)過程中的非常重要的一個環(huán)節(jié)，在軟件架構(gòu)評估中我們通常關(guān)注的質(zhì)量屬性包括性能、可用性、安全性、可修改性等。性能是指系統(tǒng)的響應(yīng)能力，即要多長時間才能對某個事件做出響應(yīng)或者在某段時間內(nèi)系統(tǒng)所能處理的事件的個數(shù)；可用性是指系統(tǒng)正常運行的時間比例，經(jīng)常用兩次故障之間的時間長度或出現(xiàn)故障時系統(tǒng)能夠恢復(fù)正常的速度來表示；安全性是指系統(tǒng)能夠向合法用戶提供服務(wù)的同時可以阻止非授權(quán)用戶訪問的企圖或拒絕服務(wù)的能力；可修改性是指系統(tǒng)能夠快速地以較高的性能價格比對系統(tǒng)進行變更的能力，通常以某些具體的變更為基準，通過評估這些變更的代價衡量可修改性。

敏感點、權(quán)衡點、風(fēng)險點的定義

敏感點，是一個或多個構(gòu)件 (和/或構(gòu)件之間的關(guān)系) 的特性。
權(quán)衡點，是影響多個質(zhì)量屬性的特性，是多個質(zhì)量屬性的敏感點。
風(fēng)險點，是指架構(gòu)設(shè)計中潛在的、存在問題的架構(gòu)決策所帶來的隱患。

大型網(wǎng)站架構(gòu)演化實例

第一階段：單體架構(gòu)
第二階段：垂直架構(gòu)（應(yīng)用、數(shù)據(jù)分離）
第三階段：緩存改善網(wǎng)站性能
第四階段：使用服務(wù)集群改善網(wǎng)站并發(fā)處理能力
第五階段：數(shù)據(jù)庫讀寫分離
第六階段：使用反向代理和CDN加速網(wǎng)站響應(yīng)
第七階段：使用分布式文件系統(tǒng)和分布式數(shù)據(jù)庫系統(tǒng)
第八階段：使用NoSQL和搜索引擎
第九階段：業(yè)務(wù)拆分
第十階段：分布式服務(wù)

數(shù)據(jù)流圖設(shè)計時應(yīng)考慮的三個原則：

(1) 復(fù)雜性最小化原則。DFD分層結(jié)構(gòu)就是把信息劃分為小的且相對獨立的一大批子集例子，這樣就可以單獨考查每一個DFD。如果要了解某個過程更加詳細的信息，可以跳轉(zhuǎn)到該過程的下一層；如果要知道一個DFD如何與其他DFD相關(guān)聯(lián)，可以跳轉(zhuǎn)到上一層的DFD進行考査。
(2) 接口最小化原則。接口最小化是復(fù)雜性最小化的一種具體規(guī)則，在設(shè)計模型時，應(yīng)使得模型中各個元素之間的接口數(shù)或連接數(shù)最小化。
(3) 數(shù)據(jù)流一致性原則。一個過程和它的過程分解在數(shù)據(jù)流內(nèi)容中是否有差別？是否存在有數(shù)據(jù)流出但沒有相應(yīng)的數(shù)據(jù)流入的加工？是否存在有數(shù)據(jù)流入但沒有相應(yīng)的數(shù)據(jù)流出的加工?

數(shù)據(jù)設(shè)計過程

數(shù)據(jù)庫概念結(jié)構(gòu)設(shè)計，包括：
a. 抽象數(shù)據(jù)
b. 設(shè)計局部ER模型
c. 合并局部模型，消除沖突
d. 重構(gòu)優(yōu)化，消除冗余

數(shù)據(jù)庫邏輯結(jié)構(gòu)設(shè)計，包括：
a. 轉(zhuǎn)化為數(shù)據(jù)模型
b. 關(guān)系范式化
c. 模式優(yōu)化
d. 設(shè)計用戶子模式

反規(guī)范化設(shè)計中，解決數(shù)據(jù)不一致性問題的三種常見方法：批處理維護、應(yīng)用邏輯、觸發(fā)器。

（1）批處理維護：指對復(fù)制列或派生列的修改積累一定的時間后，運行一批處理作業(yè)或存儲過程對復(fù)制或派生列進行修改，這只能在對實時性要求不高的情況下使用。
（2）應(yīng)用邏輯：要求必須在同一事務(wù)中對所有設(shè)計的表進行增、刪、改操作。用應(yīng)用邏輯來實現(xiàn)數(shù)據(jù)的完整性風(fēng)險較大，因為同一邏輯必須在所有的應(yīng)用中使用和維護，容易遺漏，特別是在需求變化時，不易于維護。
（3）觸發(fā)器：對數(shù)據(jù)的任何修改立即觸發(fā)對復(fù)制列或派生列的相應(yīng)修改。觸發(fā)器是實時的，而且相應(yīng)的處理邏輯只在同一地方出現(xiàn)，易于維護。一般來說，是解決這類問題比較好的辦法。

11、五大軟件架構(gòu)風(fēng)格
在做軟件架構(gòu)設(shè)計的時候，為了提高系統(tǒng)的復(fù)用性和提升開發(fā)效率，我們通常會采用一些架構(gòu)風(fēng)格。我們經(jīng)常采用的架構(gòu)風(fēng)格主要有：數(shù)據(jù)流風(fēng)格、調(diào)用返回風(fēng)格、獨立構(gòu)件風(fēng)格、虛擬機風(fēng)格、倉庫風(fēng)格。數(shù)據(jù)流風(fēng)格將前一步處理的結(jié)果作為后一步的輸入內(nèi)容，主要包含批處理序列與管道-過濾器兩種風(fēng)格，批處理序列強調(diào)的是大量整體的數(shù)據(jù)一起處理，而管道過濾器強調(diào)的是流式數(shù)據(jù)的處理；調(diào)用返回風(fēng)格主要包含主程序/子程序、面向?qū)ο箫L(fēng)格、層次結(jié)構(gòu)三種風(fēng)格，主程序/子程序是面向過程的調(diào)用，面向?qū)ο箫L(fēng)格主要是對象方法的調(diào)用，層次結(jié)構(gòu)則是層與層的方法調(diào)用；獨立構(gòu)件風(fēng)格強調(diào)的是構(gòu)件之間不直接交互從而降低系統(tǒng)的耦合性，主要包含進程通信與事件驅(qū)動兩種風(fēng)格；虛擬機風(fēng)格的特點是可以靈活的自定義場景，主要包含解釋器風(fēng)格與規(guī)則系統(tǒng)，而規(guī)則系統(tǒng)其實是在解釋器的基礎(chǔ)之上增加了經(jīng)驗規(guī)則；倉庫風(fēng)格強調(diào)的是以數(shù)據(jù)為中心，主要包含數(shù)據(jù)庫系統(tǒng)、黑板系統(tǒng)、超文本系統(tǒng)三種風(fēng)格。

12、云原生架構(gòu)原則
1、服務(wù)化原則
服務(wù)化設(shè)計原則是指通過服務(wù)化架構(gòu)拆分不同生命周期的業(yè)務(wù)單元，實現(xiàn)業(yè)務(wù)單元的獨立迭代，從而加快整體的迭代速度，保證迭代的穩(wěn)定性

2、彈性原則
彈性原則是指系統(tǒng)部署規(guī)?？梢噪S著業(yè)務(wù)量變化自動調(diào)整大小，而無須根據(jù)事先的容量規(guī)劃準備固定的硬件和軟件資源

3、可觀測原則
可觀測性更強調(diào)主動性，在云計算這樣的分布式系統(tǒng)中，主動通過日志、鏈路跟蹤和度量等手段，讓一次App點擊所產(chǎn)生的多次服務(wù)調(diào)用耗時、返回值和參數(shù)都清晰可見，。運維、開發(fā)和業(yè)務(wù)人員通過這樣的觀測能力可以實時掌握軟件的運行情況，并獲得前所未有的關(guān)聯(lián)分析能力，以便不斷優(yōu)化業(yè)務(wù)的健康度和用戶體驗

指標（Metric）、鏈路跟蹤（Tracing）和日志（Logging）這三類數(shù)據(jù)是構(gòu)建一個完整的可觀測性系統(tǒng)的“三大支柱”。而系統(tǒng)的可觀測性就是需要完整地采集、分析和展示這三類數(shù)據(jù)

4、韌性原則
韌性是指當軟件所依賴的軟硬件組件出現(xiàn)異常時，軟件所表現(xiàn)出來的抵御能力
韌性原則的實踐與常見架構(gòu)主要包括服務(wù)異步化能力、重試/限流/降級/熔斷/反壓、主從模式、集群模式、跨區(qū)域（Region）容災(zāi)、異地多活容災(zāi)等

5、過程自動化原則
通過大量自動化交付工具在CI/CD（持續(xù)集成/持續(xù)交付）流水線中的實踐，企業(yè)可以標準化企業(yè)內(nèi)部的軟件交付過程，也可以在標準化的基礎(chǔ)上實現(xiàn)自動化，即通過配置數(shù)據(jù)自描述和面向終態(tài)的交付過程，實現(xiàn)整個軟件交付和運維的自動化
6、零信任原則
基于邊界模型的傳統(tǒng)安全架構(gòu)設(shè)計，是在可信和不可信的資源之間架設(shè)一道墻
零信任模型假設(shè)防火墻邊界已經(jīng)被攻破，且每個請求都來自于不可信網(wǎng)絡(luò)，因此每個請求都需要經(jīng)過驗證，簡單說就是：永不信任，永遠驗證。在零信任模型下，每個請求都要經(jīng)過強認證，并基于安全策略得到驗證授權(quán)

7、架構(gòu)持續(xù)演進原則
技術(shù)與業(yè)務(wù)的發(fā)展速度都非?？欤诠こ虒嵺`中很少有從一開始就能夠被明確定義并適用于整個軟件生命周期的架構(gòu)模式，而是需要在一定范圍內(nèi)不斷重構(gòu)，以適應(yīng)變化的技術(shù)和業(yè)務(wù)需求
云原生架構(gòu)本身也應(yīng)該且必須具備持續(xù)演進的能力，而不是一個封閉式的、被設(shè)計后一成不變的架構(gòu)。
因此在設(shè)計時除了要考慮增量迭代、合理化目標選取等因素之外，更應(yīng)該重點考慮如何保證架構(gòu)演進與業(yè)務(wù)發(fā)展之間的平衡

論文

論文1：論基于架構(gòu)的評估方法

本文以該平臺為例，主要論述了ATAM架構(gòu)評估方法在該平臺的具體應(yīng)用，
首先，通過該平臺的業(yè)務(wù)人員和領(lǐng)域?qū)＜?，收集需求與場景；
其次，結(jié)合收集的需求及場景，通過評估小組會議，描述架構(gòu)視圖與場景實現(xiàn)；
最后，通過評估小組會議確定系統(tǒng)的質(zhì)量屬性，對屬性模型進行構(gòu)造分析，并對其中的一些權(quán)衡點做折中

架構(gòu)評估是軟件開發(fā)過程中的非常重要的一個環(huán)節(jié)，在軟件架構(gòu)評估中我們通常關(guān)注的質(zhì)量屬性，包括性能、可用性、安全性、可修改性等。
性能，是指系統(tǒng)的響應(yīng)能力，即要多長時間才能對某個事件做出響應(yīng)或者在某段時間內(nèi)系統(tǒng)所能處理的事件的個數(shù)；
可用性，是指系統(tǒng)正常運行的時間比例，經(jīng)常用兩次故障之間的時間長度或出現(xiàn)故障時系統(tǒng)能夠恢復(fù)正常的速度來表示；
安全性，是指系統(tǒng)能夠向合法用戶提供服務(wù)的同時可以阻止非授權(quán)用戶訪問的企圖或拒絕服務(wù)的能力；
可修改性，是指系統(tǒng)能夠快速地以較高的性能價格比對系統(tǒng)進行變更的能力，通常以某些具體的變更為基準，通過評估這些變更的代價衡量可修改性。

第一階段，場景和需求收集。
針對功能場景與需求的收集，描述收集方式，如調(diào)查問卷，訪談，聯(lián)合需求分析會議，現(xiàn)場觀摩等
針對質(zhì)量屬性的場景與需求收集，描述幾個性能、安全、可用性等質(zhì)量屬性

第二階段，架構(gòu)視圖與場景實現(xiàn)。
組成了架構(gòu)評估小組
首先，對ATAM的評估方法介紹
其次，架構(gòu)師，對我們的架構(gòu)視圖做了詳細的描述，如某個服務(wù)實現(xiàn)什么功能，某個技術(shù)解決了性能、可用性。

第三階段，屬性模型的構(gòu)造分析與折中。
我們對單一的質(zhì)量場景做了分析，具體說說各個質(zhì)量屬性：
沖突場景的分析，如權(quán)限控制對安全和性能的影響
輸出了質(zhì)量屬性效用樹，并對質(zhì)量場景做了優(yōu)先級排序，

論文2：論軟件系統(tǒng)架構(gòu)風(fēng)格

本文將以該平臺為例，論述架構(gòu)風(fēng)格在項目中的具體應(yīng)用。
首先，通過采用面向?qū)ο蟮募軜?gòu)風(fēng)格，抽象出了很多的對象和行為如營銷人員、合同、到訪單、首訪證據(jù)、人證的核驗、合同的創(chuàng)建與撤銷等；
其次，采用了事件驅(qū)動，保證了二次到訪提醒能及時通知到相關(guān)營銷人員；
最后，采用了解釋器風(fēng)格，讓系統(tǒng)通過舞弊決策結(jié)果、不同類型、不同級別的外部渠道，計算傭金。

在做軟件架構(gòu)設(shè)計的時候，為了提高系統(tǒng)的復(fù)用性和提升開發(fā)效率，我們通常會采用一些架構(gòu)風(fēng)格。我們經(jīng)常采用的架構(gòu)風(fēng)格主要有：數(shù)據(jù)流風(fēng)格、調(diào)用返回風(fēng)格、獨立構(gòu)件風(fēng)格、虛擬機風(fēng)格、倉庫風(fēng)格。
數(shù)據(jù)流風(fēng)格，將前一步處理的結(jié)果作為后一步的輸入內(nèi)容，主要包含批處理序列與管道-過濾器兩種風(fēng)格，批處理序列強調(diào)的是大量整體的數(shù)據(jù)一起處理，而管道過濾器強調(diào)的是流式數(shù)據(jù)的處理；
調(diào)用返回風(fēng)格，主要包含主程序/子程序、面向?qū)ο箫L(fēng)格、層次結(jié)構(gòu)三種風(fēng)格，主程序/子程序是面向過程的調(diào)用，面向?qū)ο箫L(fēng)格主要是對象方法的調(diào)用，層次結(jié)構(gòu)則是層與層的方法調(diào)用；
獨立構(gòu)件風(fēng)格，強調(diào)的是構(gòu)件之間不直接交互從而降低系統(tǒng)的耦合性，主要包含進程通信與事件驅(qū)動兩種風(fēng)格；
虛擬機風(fēng)格，特點是可以靈活的自定義場景，主要包含解釋器風(fēng)格與規(guī)則系統(tǒng)，而規(guī)則系統(tǒng)其實是在解釋器的基礎(chǔ)之上增加了經(jīng)驗規(guī)則；
倉庫風(fēng)格，強調(diào)的是以數(shù)據(jù)為中心，主要包含數(shù)據(jù)庫系統(tǒng)、黑板系統(tǒng)、超文本系統(tǒng)三種風(fēng)格。

論文3：論基于架構(gòu)的軟件開發(fā)方法（ABSD）及其應(yīng)用

本文將以該系統(tǒng)為例，論述基于架構(gòu)的軟件開發(fā)方法在項目中的應(yīng)用。
首先，在架構(gòu)需求階段，通過用戶訪談、問卷調(diào)查、現(xiàn)場觀摩、構(gòu)造原型的方式全面獲取了需求；
其次，在架構(gòu)復(fù)審階段，采用基于場景的評估方法保障了項目的質(zhì)量；
最后，在架構(gòu)演化階段，靈活運用jira來管理與控制需求的變動

論點

在做系統(tǒng)架構(gòu)設(shè)計時，我們經(jīng)常會使用基于架構(gòu)的軟件設(shè)計方法（ABSD）。ABSD是架構(gòu)驅(qū)動的，強調(diào)由商業(yè)，質(zhì)量和功能需求的組合驅(qū)動軟件架構(gòu)設(shè)計。強調(diào)用視角與視圖描述軟件架構(gòu)，用用例與質(zhì)量場景描述需求。
基于架構(gòu)的軟件設(shè)計方法（ABSD）包括架構(gòu)需求、架構(gòu)設(shè)計、架構(gòu)文檔化、架構(gòu)復(fù)審、架構(gòu)實現(xiàn)和架構(gòu)演化六個階段。

• 架構(gòu)需求階段 明確用戶對系統(tǒng)在功能、行為、性能、設(shè)計約束等方面的期望，包括需求獲取、標識構(gòu)件和需求評審；
• 架構(gòu)設(shè)計階段 根據(jù)需求生成并調(diào)整架構(gòu)決策，包括提出架構(gòu)模型、映射構(gòu)件、分析構(gòu)件相互作用、產(chǎn)生架構(gòu)和設(shè)計評審；設(shè)計評審之后可能還會重新對構(gòu)件映射做出調(diào)整，所以其中的活動也存在重復(fù)多次的情形；
• 架構(gòu)文檔化階段 對架構(gòu)設(shè)計階段的成果進行分析和整理后形成文檔，產(chǎn)生架構(gòu)規(guī)格說明書和質(zhì)量設(shè)計說明書；
• 架構(gòu)復(fù)審階段 評價架構(gòu)能否滿足需求與實現(xiàn)質(zhì)量屬性、層次構(gòu)件劃分是否合理，標識潛在的風(fēng)險，及早發(fā)現(xiàn)設(shè)計中的缺陷錯誤；
• 架構(gòu)實現(xiàn)階段 對架構(gòu)進行實現(xiàn)，包括架構(gòu)分析與設(shè)計、構(gòu)件實現(xiàn)、組裝和系統(tǒng)測試；
• 架構(gòu)演化階段 主要解決開發(fā)中用戶需求變更問題，包括架構(gòu)演化計劃、構(gòu)件變動、更新構(gòu)件相互作用、構(gòu)件組裝測試與技術(shù)評審。

結(jié)合實際

架構(gòu)需求階段，前期、中期、后期，如何獲取需求，結(jié)合原型方法，讓用戶也參與其中，為以后項目通過驗收提供了有力支持。
架構(gòu)復(fù)審階段，采用基于場景的評估方法保障了項目的質(zhì)量。場景和需求收集、架構(gòu)視圖與場景實現(xiàn)、屬性模型的構(gòu)造分析與折中。最終輸出了質(zhì)量效用樹，也分析出了其中的風(fēng)險點、敏感點、權(quán)衡點等。
架構(gòu)演化階段，需求的變動可能影響的多個構(gòu)建，要做好記錄跟蹤，否則需求變得不可控制。我們使用JIRA平臺，維護項目的需求池。每2周進行一次迭代，每個迭代就是一個架構(gòu)演化計劃，

論文4：論負載均衡技術(shù)在web系統(tǒng)中的應(yīng)用

負載均衡（Load Balance），它在網(wǎng)絡(luò)現(xiàn)有結(jié)構(gòu)之上可以提供一種廉價、有效、透明的方法來擴展網(wǎng)絡(luò)設(shè)備和服務(wù)器的帶寬，并可以在一定程度上增加吞吐量、加強網(wǎng)絡(luò)數(shù)據(jù)處理能力、提高網(wǎng)絡(luò)的靈活性和可用性等。用官網(wǎng)的話說，它充當著網(wǎng)絡(luò)流中“交通指揮官”的角色，“站在”服務(wù)器前處理所有服務(wù)器端和客戶端之間的請求，從而最大程度地提高響應(yīng)速率和容量利用率，同時確保任何服務(wù)器都沒有超負荷工作。如果單個服務(wù)器出現(xiàn)故障，負載均衡的方法會將流量重定向到其余的集群服務(wù)器，以保證服務(wù)的穩(wěn)定性。當新的服務(wù)器添加到服務(wù)器組后，也可通過負載均衡的方法使其開始自動處理客戶端發(fā)來的請求

1、輪詢法會將收到的請求循環(huán)分配到服務(wù)器集群中的每臺機器，即有效服務(wù)器上。如果使用這種方式，所有的標記進入分發(fā)的服務(wù)器應(yīng)該有相近的資源容量以及負載形同的應(yīng)用程序。如果所有的服務(wù)器有相同或者相近的性能那么選擇這種方式會使服務(wù)器負載相對均衡?；谶@個前提，輪循調(diào)度是一個簡單而有效的分配請求的方式。然而對于服務(wù)器不同的情況，選擇這種方式就意味著能力比較弱的服務(wù)器也會在下一輪循環(huán)中接受輪循，即使這個服務(wù)器已經(jīng)不能再處理當前這個請求了。這可能導(dǎo)致能力較弱的服務(wù)器超載。

2、加權(quán)輪詢算法解決了簡單輪循調(diào)度算法的缺點：傳入的請求按順序被分配到集群中服務(wù)器，但是會考慮提前為每臺服務(wù)器分配的權(quán)重。配置人員只是簡單的通過服務(wù)器的處理能力來定義各臺服務(wù)器的權(quán)重。例如，性能最強的服務(wù)器A給的權(quán)重是100，同時性能最低的服務(wù)器給的權(quán)重是50。這意味著在服務(wù)器B接收到第一個請求之前前，服務(wù)器A會連續(xù)的接受到2個請求，以此類推。

3、最小連接數(shù)算法，上述兩種方法都沒有考慮的是系統(tǒng)不能識別在給定的時間里保持了多少連接。因此可能發(fā)生，服務(wù)器B服務(wù)器收到的連接比服務(wù)器A少但是它已經(jīng)超載，因為服務(wù)器B上的用戶打開連接持續(xù)的時間更長。這就是說連接數(shù)即服務(wù)器的負載是累加的。這種潛在的問題可以通過"最少連接數(shù)"算法來避免：傳入的請求是根據(jù)每臺服務(wù)器當前所打開的連接數(shù)來分配的。即活躍連接數(shù)最少的服務(wù)器會自動接收下一個傳入的請求?；旧虾秃唵屋喸兊脑瓌t相同：所有擁有虛擬服務(wù)的服務(wù)器資源容量應(yīng)該相近。值得注意的是，在流量較低的配置環(huán)境中，各服務(wù)器的流量并不是相同的，會優(yōu)先考慮第一臺服務(wù)器。

論文背景

2021年8月，我有幸參與了某地產(chǎn)集團智慧營銷平臺項目的研發(fā)，該平臺主要采用端、邊、云的技術(shù)架構(gòu)，以實現(xiàn)人員到訪管理、人臉識別、同行人分析、首訪管理，認購簽約、人證核驗、飛單判斷、飛單管理、到訪推送等功能。我在該項目中擔(dān)任系統(tǒng)架構(gòu)師角色，主要負責(zé)系統(tǒng)架構(gòu)設(shè)計的相關(guān)工作。本文以該平臺為例，主要論述了ATAM架構(gòu)評估方法在該平臺的具體應(yīng)用，首先通過該平臺的業(yè)務(wù)人員和領(lǐng)域?qū)＜沂占枰c場景；其次，結(jié)合收集的需求及場景，通過評估小組會議，描述架構(gòu)視圖與場景實現(xiàn)；最后，通過評估小組會議確定系統(tǒng)的質(zhì)量屬性，對屬性模型進行構(gòu)造分析，并對其中的一些權(quán)衡點做折中。通過以上架構(gòu)評估的實施過程，對后續(xù)項目的順利實施提供了有力的支持，最終項目順利上線，受到集團領(lǐng)導(dǎo)及用戶的一致好評。

近年來，隨著國家“住房不炒” 政策寫入政府工作報告，疊加疫情影響，國民收入逐漸下降，整個國民經(jīng)濟增速也進入了下降趨勢。作為國民經(jīng)濟三架馬車之一的房地產(chǎn)行業(yè)，也開始進入了下行通道。我所在的某地產(chǎn)集團，2021年上半年，居住房地產(chǎn)業(yè)務(wù)同比下降30%以上，在這種情況下，傭金支付的成本占比卻在不斷增高，高達上億元。而這其中，渠道舞弊導(dǎo)致的傭金支付，是一直以來困擾集團的難題。所謂渠道舞弊，是指自然到訪的客戶，在職業(yè)顧問、外部渠道員工等人的暗箱操作下，使其變成外部渠道的客戶。外部渠道的客戶在進行購房簽約后，集團需要對外部渠道支付一定比例的傭金。也正是基于這樣的背景下，2021年9月，集團以數(shù)字化為契機，利用圖像識別技術(shù)，打造整個集團的智慧營銷平臺，徹底解決渠道舞弊現(xiàn)象，并為營銷業(yè)務(wù)降本增效。本系統(tǒng)在營銷門店部署邊緣服務(wù)器，并采用最新的視頻流抽幀及圖片特征值不可逆加密技術(shù)，不需要存儲原始圖像信息，從而符合國家個人信息保護法對隱私合規(guī)的要求。
該平臺采用SpringCloud作為技術(shù)基礎(chǔ)架構(gòu)，Nacos作為服務(wù)注冊中心和配置中心；Redis Cluster作為緩存和分布式鎖，Kafka作為到訪明細的消息隊列，用來接收所有邊緣服務(wù)器上報的到訪明細，削峰填谷；Elasticsearch作為到訪記錄及用戶到訪備案，支持全文檢索。該平臺通過部署在全國各個營銷門店的邊緣服務(wù)器，利用圖形識別、同行人分析技術(shù)，識別到訪人及同行人，形成到訪信息，上報至云端Kafka，生成首訪信息及到訪記錄；客戶在購買簽約時，生成簽約信息，并利用小程序或營銷門店的人證一體機，完成簽約人的人證核驗；系統(tǒng)會自動對已核驗的簽約信息進行飛單邏輯處理，校驗當前簽約是否屬于渠道舞弊，并根據(jù)校驗結(jié)果來作為傭金支付的依據(jù)。我以系統(tǒng)架構(gòu)師的角色全程參與了此平臺的建設(shè)，智慧營銷平臺由BP、產(chǎn)品組、研發(fā)組、測試組、人工智能組等共32位人組成的團隊，耗時9個月完成。項目于2022年5月開始在多個城市試運行上線，實際運行效果遠超期望，獲得了集團領(lǐng)導(dǎo)的一致好評。