对软件架构设计的一些总结和理解
2019獨角獸企業(yè)重金招聘Python工程師標準>>>
1. 軟件架構(gòu)設(shè)計的What & Why
● 啥是軟件架構(gòu)（Software Architecture）？
軟件架構(gòu)是指在一定的設(shè)計原則基礎(chǔ)上，從不同角度對組成系統(tǒng)的各部分進行搭配和安排，形成系統(tǒng)的多個結(jié)構(gòu)而組成架構(gòu)，它包括該系統(tǒng)的各個組件，組件的外部可見屬性及組件之間的相互關(guān)系。組件的外部可見屬性是指其他組件對該組件所做的假設(shè)。
軟件架構(gòu)設(shè)計就是從宏觀上說明一套軟件系統(tǒng)的組成與特性。
軟件架構(gòu)設(shè)計是一系列有層次的決策 ，比如：功能與展現(xiàn)的決策；技術(shù)架構(gòu)的決策；自主研發(fā)還是合作；商業(yè)軟件還是開源軟件 。
?
?
● 為啥要進行軟件架構(gòu)設(shè)計？
業(yè)務(wù)需求層出不窮；軟件系統(tǒng)越來越復(fù)雜；參與的人越來越多；共性和特殊性的問題越來越多；技術(shù)發(fā)展日異月新；……
?
2. 軟件架構(gòu)師
?
2.1. 軟件架構(gòu)師是干什么的
?
| 能夠統(tǒng)領(lǐng)全局的大牛 | 良好的大局觀 |
| 能夠?qū)⑿枨筠D(zhuǎn)換為技術(shù) ??? | 洞悉前沿與市場嗅覺 |
| 能夠為軟件研發(fā)提供指導(dǎo) ?? | ?見多識廣的大牛 |
| 需要全面思考軟件系統(tǒng)方方面面的問題 ??? | 縝密地思考問題 |
| 能夠攻關(guān)和搞定重要技術(shù)難題 ??? | 公司可信賴的支柱 |
?
2.2. 架構(gòu)師的素質(zhì)
?
| 全局思維 ? | 從業(yè)務(wù)、市場，到技術(shù)實現(xiàn)； 從軟件的過去、現(xiàn)在，到將來； 從外部客戶，到內(nèi)部研發(fā)； 從軟件研發(fā)，到硬件部署； 從功能實現(xiàn)，到運行效率?? |
| 戰(zhàn)略思維 ? | 在所在行業(yè)的發(fā)展戰(zhàn)略； 在業(yè)務(wù)領(lǐng)域的發(fā)展戰(zhàn)略； 在技術(shù)方向的發(fā)展戰(zhàn)略； 在潛在市場的發(fā)展戰(zhàn)略。 |
| 前瞻思維 ? | 市場趨勢的發(fā)展動向； 前沿技術(shù)的發(fā)展動向； 競爭對手的發(fā)展動向； 合作伙伴的發(fā)展動向。 |
| 抽象思維 ? | 各項業(yè)務(wù)需求：抽象成功能模塊； 各項功能的實現(xiàn)：抽象成軟件架構(gòu)。? |
| 逆向思維 | 假如不實現(xiàn)會怎樣？ 假如沒搞定會怎樣？ 假如沒有它會怎樣？ 假如被延期會怎樣？ |
?
2.3.? 架構(gòu)師的分類
隨著行業(yè)和社會的發(fā)展，架構(gòu)師的定義和分類越來越廣泛和細分，廣泛和細分其實并不矛盾，如果“廣泛”是x軸，“細分”是y軸，則二維坐標系x和y軸中間的任一點就是一種架構(gòu)師類別。但總體來說，或目前來說，集合業(yè)界的大致認知，總結(jié)如下：
?
| No. | 分類?????????????? | 描述 |
| 1 | 解決方案架構(gòu)師 | 與客戶探討業(yè)務(wù)需求，將業(yè)務(wù)、市場，與技術(shù)、產(chǎn)品結(jié)合起來，為客戶提供解決他們需求的方案。 |
| 2 | 系統(tǒng)架構(gòu)師 | 也稱應(yīng)用架構(gòu)師。最終確認和評估系統(tǒng)需求，并將業(yè)務(wù)轉(zhuǎn)換為技術(shù)，為研發(fā)人員制訂核心框架與技術(shù)規(guī)范 為研發(fā)工作澄清技術(shù)細節(jié)并掃清技術(shù)障礙 。 |
| 3 | 平臺架構(gòu)師 | 這里的平臺其實包括兩個平臺，一個是系統(tǒng)平臺，也就是負責搭建多個系統(tǒng)整合的系統(tǒng)應(yīng)用平臺；另外一個其實是基礎(chǔ)平臺，是專門負責搭建基礎(chǔ)技術(shù)平臺；兩者其 實區(qū)別蠻大，也經(jīng)常容易被從業(yè)人員混亂。舉個簡單例子，金蝶有平臺架構(gòu)師一職，但是金蝶BOSS應(yīng)用和金蝶中間件兩者招聘的對象和技術(shù)要求是截然不同的。 |
| 4 | 業(yè)務(wù)架構(gòu)師 | 業(yè)務(wù)架構(gòu)其實已經(jīng)開始脫離技術(shù)層面了，但是它要求架構(gòu)師有跨越多系統(tǒng)的大局觀，去整合和組織不同系統(tǒng)的技術(shù)平臺與交互模式。其實這個職位的未來也就是CIO了。 |
| 5 | 網(wǎng)絡(luò)架構(gòu)師 | 過去，我們可能聽的最多的是網(wǎng)絡(luò)工程師。不錯，一個優(yōu)秀的網(wǎng)絡(luò)架構(gòu)師必須有足夠的網(wǎng)絡(luò)技術(shù)基底，并且它的關(guān)注點也是系統(tǒng)的基礎(chǔ)架構(gòu)。比如說如果搭建并優(yōu)化集群環(huán)境，如果構(gòu)建基于云計算的系統(tǒng)應(yīng)用與部署等等。它對于像淘寶、騰訊這樣的互聯(lián)網(wǎng)公司是極其重要的。 |
| 6 | 移動架構(gòu)師 | 移動互聯(lián)網(wǎng)的迅猛發(fā)展橫向和縱向都細分出了很多新的職責和崗位，移動架構(gòu)師的職責和作用日益重要，既要整體和全局考慮整個前后端的軟件系統(tǒng)架構(gòu)，又要重點深入移動客戶端的架構(gòu)設(shè)計的方方面面，既要有跨平臺思維，又要拿捏好原生和混合開發(fā)的尺度，另外移動應(yīng)用的特點，導(dǎo)致移動架構(gòu)師必須要比傳統(tǒng)系統(tǒng)架構(gòu)師更加注重非功能性的質(zhì)量屬性。 |
| 7 | 前端架構(gòu)師 | 這也是移動互聯(lián)網(wǎng)的迅猛發(fā)展而細分出來的新的職責和崗位，這里的前端特指網(wǎng)站開發(fā)中的前端，主要考慮前端呈現(xiàn)層的設(shè)計（HTML/CSS/JS/AJAX/RIA/…），跨瀏覽器設(shè)計等等。 |
| 8 | ... | ... |
?
3.? 軟件需求
軟件架構(gòu)設(shè)計中常說需求驅(qū)動架構(gòu)設(shè)計，可見需求在整個架構(gòu)設(shè)計中起到了關(guān)鍵指引和方向的作用，如果以目標導(dǎo)向為原則，則需求的滿足和實現(xiàn)就是架構(gòu)設(shè)計的終極目標。
OK，在進行架構(gòu)設(shè)計之前，我們先看下軟件需求。
3.1.? 軟件需求怎么來的（軟件需求的過程）
?
| 階段 | 需求階段 | 說明 | 什么人做什么事 | 可能產(chǎn)生的文檔 | ||
| 客戶方 | 實施方 | 客戶方 | 實施方 | |||
| 1 | 業(yè)務(wù)需求 | 來自客戶的原始需求，背景描述，業(yè)務(wù)訴求和期望目標。 | 項目負責人或接口人描述需求或提供客戶方需求文檔。 | 銷售或售前接觸客戶，聽取和記錄需求。 | 工作說明書（SOW），或邀標書 | 售前的方案建議書 |
| 2 | 用戶需求 | 通常是在問題定義的基礎(chǔ)上進行用戶訪談、調(diào)查，對用戶使用的場景進行整理，從而建立從用戶角度的需求。 | 項目負責人或接口人接受訪談和調(diào)研。 | 需求分析師或項目經(jīng)理等進行需求調(diào)研。 | ? | 調(diào)研計劃、用戶需求調(diào)研提問庫、調(diào)研日志、用戶需求說明書 |
| 3 | 軟件需求 | 從系統(tǒng)實現(xiàn)的角度描述的需求。開發(fā)人員（設(shè)計和分析人員）在業(yè)務(wù)需求、用戶需求的基礎(chǔ)上形成的。 | ? | 需求分析師或項目經(jīng)理、架構(gòu)師等討論和細化需求，編寫需求文檔 | ? | SRS（Software Requirement Specification）軟件需求規(guī)格說明書 |
?
3.2.? 軟件需求的分類：
另外，也有McCall軟件質(zhì)量模型：
注：在架構(gòu)設(shè)計中，對非功能性需求的重視程度，也會影響架構(gòu)設(shè)計的好與劣；但也要平衡過渡設(shè)計和適可而止的關(guān)系。
?
4.? 軟件架構(gòu)的過程
業(yè)界軟件架構(gòu)設(shè)計的方法論很多，各有各自的應(yīng)用場景和特點，下文結(jié)合ADMEMS（Architecture Design Method has been Extended to Method System）架構(gòu)設(shè)計方法論說明軟件架構(gòu)的過程：
?
| 架構(gòu)階段 | 目標 | 方式方法 | 現(xiàn)實工作場景 |
| 預(yù)架構(gòu)階段 | 全面理解需求；需求結(jié)構(gòu)化，摒棄“需求列表”，建立二維需求觀（ADMEMS矩陣）。 | 使用ADMEMS矩陣方法，捋清需求間關(guān)系和發(fā)現(xiàn)衍生需求。 | 1、與人：與項目經(jīng)理、需求分析師等內(nèi)部需求人員了解需求；與客戶了解需求（不建議架構(gòu)師做需求分析師角色）。 |
| 概念架構(gòu) | 高層組件及其關(guān)系 | 1、初步設(shè)計，基于關(guān)鍵功能，借助魯棒圖進行以發(fā)現(xiàn)職責為目的的初步設(shè)計（不是必須）。 | 1、參與內(nèi)部討論：項目可行性分析、討論，從需求、技術(shù)、人力、風險等角度提供建議。 |
| 細化架構(gòu) | ? | 5視圖法 | 在項目概要設(shè)計階段，進行架構(gòu)設(shè)計，制定規(guī)范和約定，為詳細設(shè)計提供指導(dǎo)。 |
| 實現(xiàn) | 詳細設(shè)計 | 架構(gòu)設(shè)計形成詳細設(shè)計文檔 | 在項目實現(xiàn)階段，對開發(fā)人員提供規(guī)范指引和技術(shù)支持。 |
?
注：架構(gòu)設(shè)計的過程和內(nèi)容的不是固定不變的，現(xiàn)實中，比如售前提供解決方案中，很多時候需要架構(gòu)師提供細化架構(gòu)中才會深思的邏輯架構(gòu)、物理架構(gòu)等，這時候，架構(gòu)師就需要有螺旋思維和跳躍思維的方式，就像武功中，招式是死的，人是活的，要學會靈活運用。
?
5.? 軟件架構(gòu)設(shè)計的方式方法
?
5.1.? 多視圖法
多視圖方法是業(yè)界廣泛認同的一種架構(gòu)設(shè)計思路，包括：
● SEI的3視圖法：
模塊視圖、組件-連接器視圖、分配視圖。
● 西門子的4視圖法：
概念視圖、模塊視圖、代碼視圖、執(zhí)行視圖。
● RUP的4+1視圖法：
用例視圖、邏輯視圖、開發(fā)視圖、進程視圖、物理視圖。
● 聯(lián)邦企業(yè)架構(gòu)框架：
技術(shù)架構(gòu)視圖、信息架構(gòu)視圖、應(yīng)用架構(gòu)視圖、業(yè)務(wù)架構(gòu)視圖。
● ……
5.2.? 5視圖法
5視圖法分析的意義：
● 全面分析軟件系統(tǒng)方方面面的問題
● 盡早地發(fā)現(xiàn)和排除項目風險與不確定因素
● 從不同角度去展現(xiàn)要設(shè)計的軟件系統(tǒng)
● 為項目進行中不同的干系人提供指導(dǎo)：
??? -- 邏輯架構(gòu)描述系統(tǒng)功能，并指導(dǎo)系統(tǒng)測試
??? -- 開發(fā)架構(gòu)規(guī)范軟件的層次及代碼風格
??? -- 數(shù)據(jù)架構(gòu)指導(dǎo)數(shù)據(jù)庫的設(shè)計
??? -- 運行架構(gòu)定義了一些關(guān)鍵過程的設(shè)計
??? -- 物理架構(gòu)明確軟件如何部署與實施
5.3.? 5視圖法設(shè)計步驟
兩種觀念：
?
| 觀念 | 設(shè)計步驟 |
| 觀念一 | 順序進行： 1、邏輯架構(gòu)。 2、開發(fā)架構(gòu) 3、數(shù)據(jù)架構(gòu) 4、運行架構(gòu) 5、物理架構(gòu) |
| 觀念二 | 5個視圖是穿插進行設(shè)計的，對復(fù)雜系統(tǒng)而言，根本不可能將邏輯視圖設(shè)計完了后再考慮其它視圖。 |
| 筆者觀念 | 觀念一和觀念二的情況在現(xiàn)實狀況中都可能存在，要根據(jù)具體情況具體分析，但總體而言，5視圖穿插進行思考更有利于思考的全局性和完整性。 |
?
5.4.? 如何進行5視圖法的設(shè)計
以下5視圖表格中的工具和方法每個架構(gòu)師或略有差異，以下僅為參考。
5.4.1.? 邏輯架構(gòu)
邏輯架構(gòu)的重點是考慮軟件功能性需求。
| No. | 考慮的方面 | 產(chǎn)出物 | 工具 | 說明 |
| 1 | 系統(tǒng)功能劃分為幾個子系統(tǒng)與功能模塊？ | 系統(tǒng)功能樹 | 樹型結(jié)構(gòu)圖 | ? |
| 2 | 向什么用戶提供什么樣的功能？ | 用例模型 | UML用例圖 | 體現(xiàn)用戶和行為 |
| 3 | 每個功能都是怎樣的操作流程與分支？ | 用例描述 | 用例描述表 ? | 含輸入輸出、事件流分析； 不要有界面描述 |
| UML活動圖 | 進行業(yè)務(wù)流程分析，包括泳道圖 | |||
| 4 | 如何通過界面與用戶交互？怎樣交互？ | 魯棒分析 | 魯棒圖 | 通過對“用例描述表”進行原文分析法揀出名詞和動詞 |
| 5 | 應(yīng)當設(shè)計哪些類與界面？怎樣設(shè)計？ | 領(lǐng)域模型 | UML類圖 | ? |
| 6 | 與哪些外部系統(tǒng)接口？怎樣接口？ | 接口描述 | UML類圖 | ? |
?
5.4.2.? 開發(fā)架構(gòu)
?
開發(fā)架構(gòu)重點關(guān)注的是開發(fā)編碼實現(xiàn)方面的問題。
?
| No. | 考慮的方面 | 產(chǎn)出物 | 工具 | 說明 |
| 1 | 分層結(jié)構(gòu)設(shè)計 | 分層架構(gòu)圖（開發(fā)架構(gòu)圖） | 各種繪圖工具 | 好的分層結(jié)構(gòu)支持自動化測試 |
| 2 | 開發(fā)技術(shù)選項 | 開發(fā)語言 開發(fā)框架 開發(fā)工具 | ? | 考慮商用產(chǎn)品、開源框架、自研框架 |
| 3 | 模塊劃分 | 源碼工程；Project目錄結(jié)構(gòu)； 分包(分庫) | ? | ? |
| 4 | 開發(fā)規(guī)范 | 開發(fā)/編碼規(guī)范文檔； | ? | ? |
| 5 | 軟件質(zhì)量屬性 | 分析和決策結(jié)果 | ? | 考慮運行期和開發(fā)期軟件質(zhì)量屬性，并權(quán)衡利弊進行決策。 |
?
5.4.3.? 數(shù)據(jù)架構(gòu)
?
數(shù)據(jù)架構(gòu)不僅僅要考慮開發(fā)中涉及到的數(shù)據(jù)庫，實體模型，也要考慮物理架構(gòu)中數(shù)據(jù)存儲的設(shè)計。
| No. | 考慮的方面 | 產(chǎn)出物 | 工具 | 說明 |
| 1 | 數(shù)據(jù)是集中還是分布存儲的？如何考慮分布式存儲？ | 數(shù)據(jù)架構(gòu)圖 | ? | ? |
| 2 | 領(lǐng)域模型到數(shù)據(jù)庫表的轉(zhuǎn)換？表結(jié)構(gòu)關(guān)系的設(shè)計？ | 邏輯模型 物理模型 ER圖 | Power Designer Visio | ? |
| 3 | 實體如何設(shè)計？充血模型和貧血模型？ | UML類圖 | ? | ? |
| 4 | 使用什么數(shù)據(jù)庫？關(guān)系型還是非關(guān)系型？ | 選型結(jié)果 | ? | ? |
?
?
| 關(guān)系型數(shù)據(jù)庫 | 非關(guān)系型數(shù)據(jù)庫（NoSQL） |
| Oracle（首次發(fā)行：1980年） MySQL（首次發(fā)行：1995） MS SQL Server（首次發(fā)行：1989） PostgreSQL（首次發(fā)行：1989） IBM DB2（首次發(fā)行：1983） Microsoft Access（首次發(fā)行：1992） Sybase ASE（首次發(fā)行：1987） SQLite（首次發(fā)行：2000） ……? | MongoDB（首次發(fā)行：2009） Cassandra（首次發(fā)行：2008） Apache CouchDB Hbase Redis db4o BaseX ……? |
?
?
5.4.4.? 運行架構(gòu)
?
運行架構(gòu)關(guān)注的不再是全局而是局部，著重關(guān)注那些關(guān)鍵點與難點，常常需要技術(shù)攻關(guān)與預(yù)研。主要考慮控制流、通訊機制、資源爭用、鎖機制、同步異步、并發(fā)、串行，同時也要考慮質(zhì)量屬性。
| No. | 考慮的方面 | 產(chǎn)出物 | 工具 | 說明 |
| 1 | 運行：同步vs.異步；并發(fā)vs.串行 | 考慮開發(fā)架構(gòu)中代碼的實現(xiàn)。 | ? | ? |
| 2 | 交互：對象間交互；狀態(tài)轉(zhuǎn)換 | 考慮開發(fā)架構(gòu)的合理性，到類、到接口、到代碼。 | ? | ? |
| 3 | 質(zhì)量：安全；可靠；可伸縮 | 考慮開發(fā)架構(gòu)的合理性 | ? | ? |
| 4 | 性能：響應(yīng)時間；吞吐量 | 估算： 在線人數(shù)、并發(fā)人數(shù)； 每秒事務(wù)量； 響應(yīng)時間。 | ? | ? |
?
?
5.4.5.? 物理架構(gòu)
?
物理架構(gòu)主要考慮硬件選擇和拓撲結(jié)構(gòu)，軟件到硬件的映射，軟硬件的相互影響。
| ? | 考慮的方面 | 產(chǎn)出物 | 工具 | 說明 |
| 1 | 網(wǎng)絡(luò)方面：網(wǎng)絡(luò)拓撲；網(wǎng)絡(luò)設(shè)備；安全機制 | 拓撲圖 安全規(guī)范 | ? | ? |
| 2 | 性能方面：可靠性、可伸縮性 | 需要什么樣設(shè)備性能 | ? | ? |
| 3 | 部署方面：集中式還是分布式；組件部署 | 部署圖 ? | ? | ? |
?
?
6.? 一個思考，誰驅(qū)動了架構(gòu)設(shè)計？
?
需求驅(qū)動了架構(gòu)設(shè)計？
質(zhì)量屬性了驅(qū)動了架構(gòu)設(shè)計（ADD）？
領(lǐng)域驅(qū)動了架構(gòu)設(shè)計（DDD）？
風險驅(qū)動了架構(gòu)設(shè)計？
質(zhì)疑驅(qū)動了架構(gòu)設(shè)計？
……
到底是誰驅(qū)動了架構(gòu)設(shè)計？我們以船舶設(shè)計建造為例，來看這些問題：
| 目標和結(jié)果 à | 問題 à | 回答 à | 小結(jié) |
| 設(shè)計和制造一艘遠洋貨輪，能經(jīng)歷數(shù)月海上顛簸和長途跋涉，并保證貨物的安全和完整，最后能順利抵達目標港口。 | 我們?yōu)槭裁匆O(shè)計和制造這樣的大船？ | 市場有這個需求； 獲利很豐厚； 解決就業(yè)； …… | 不管是外部需求還是內(nèi)部的需求，都是需求。不正是需求驅(qū)動嗎？ |
| 如何保證貨船能長途航行并經(jīng)受波濤和風雨？ | 船要造的結(jié)實； | 魯棒性 | 這些不正是質(zhì)量屬性驅(qū)動設(shè)計嗎？ |
| 引擎設(shè)計的強勁； | 性能 | ||
| 船的燃料充足； | 持續(xù)可用性 | ||
| 裝備衛(wèi)星電話、GPS、雷達等設(shè)備 | 互操作性 | ||
| 貨物和人員要安全 | 安全性 | ||
| 船舶設(shè)計師怎么設(shè)計這樣的船舶？ | 現(xiàn)在都會通過計算機進行船舶的CAD和3D模型設(shè)計。 | 是不是佷似領(lǐng)域模型驅(qū)動了設(shè)計？ | |
| 造船一定有很多風險吧？ | 那是，比如訂貨方客戶有時提出改裝船舶的意見（需求變化的風險）；有時某些工藝成品率不穩(wěn)定（質(zhì)量風險）；等等。 | 所有可能的風險點在設(shè)計時都要考慮到，做好預(yù)案，才能保證架構(gòu)設(shè)計的可行性和靈活性，風險驅(qū)動了架構(gòu)設(shè)計。 | |
| 上面怎么提了那么多問題，其實還有很多問題，比如…… | 嗯，你現(xiàn)在有不少疑問了。 | 不斷的質(zhì)疑架構(gòu)設(shè)計中可能存在各種問題，有質(zhì)疑才有思考，才有解決方案，從而推動架構(gòu)設(shè)計的不斷完善。 |
?
總結(jié)：
以上幾個方面都能驅(qū)動架構(gòu)設(shè)計，并不是零和的規(guī)則，而是一個立方體從不同方向看的問題。以上方面有些是指導(dǎo)思想，有些是行動方式，有的兼而有之，闡述方式看似不同，終極目標還是造出大船（實現(xiàn)需求），造出好船（質(zhì)量屬性），怎么造（領(lǐng)域模型），造的順利（風險控制），挑不出毛病（架構(gòu)師自己先質(zhì)疑問題并解決了）。
?
?
7.? 軟件架構(gòu)設(shè)計的誤區(qū)
?
● 高開高走落不到實處
●?理想與現(xiàn)實需要折中
●?遺漏關(guān)鍵性約束與非功能需求
●?為虛無的未來埋單而過度設(shè)計
●?過早做出關(guān)鍵性決策
●?客戶說啥就是啥成為醬油哥
●?埋頭干活兒缺乏前瞻性
●?架構(gòu)設(shè)計還要考慮系統(tǒng)可測性
●?架構(gòu)設(shè)計不要企圖一步到位
?
?
8.? 部分參考資料
?
溫昱的《一線架構(gòu)師實踐指南》
轉(zhuǎn)載于:https://my.oschina.net/u/3658506/blog/1650007
總結(jié)
以上是生活随笔為你收集整理的对软件架构设计的一些总结和理解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 腾讯滑动验证
- 下一篇： 验证tomcat安装成功