自從5月8號(hào)寫完架構(gòu)設(shè)計(jì)三部曲的***部如何寫架構(gòu)設(shè)計(jì)說明書，到現(xiàn)在快20多天了，這段時(shí)間主要準(zhǔn)備了下系統(tǒng)分析師的考試，當(dāng)然還有各種工作上的雜事，于是也就拖到現(xiàn)在寫第二部如何評(píng)審架構(gòu)設(shè)計(jì)說明書。當(dāng)然這個(gè)是從評(píng)審的角度來看的，其實(shí)從編制架構(gòu)設(shè)計(jì)說明書的角度來看，也可以闡述具體如何編寫架構(gòu)設(shè)計(jì)說明書，就像高考作文一樣，評(píng)審總是有些采分點(diǎn)的嘛，那么對(duì)于編制架構(gòu)設(shè)計(jì)說明書來說，哪些是我們應(yīng)該準(zhǔn)備的采分點(diǎn)呢？我們?cè)诰幹频倪^程中需要重點(diǎn)注意哪些章節(jié)的哪些內(nèi)容呢？這就是我接下來想和大家分享的。

[[135498]]

根據(jù)***部文章我們知道一篇架構(gòu)設(shè)計(jì)說明書大致章節(jié)應(yīng)該是這樣的：

• 文檔概述：包含項(xiàng)目背景、項(xiàng)目目標(biāo)、文檔版本信息、目標(biāo)讀者、參考文檔、名詞解釋之類的一般文檔都會(huì)有的章節(jié)；
• 整體架構(gòu)：主要從整個(gè)IT層描述系統(tǒng)所處的位置，與周邊關(guān)聯(lián)系統(tǒng)之間的調(diào)用關(guān)系；
• 邏輯架構(gòu)：系統(tǒng)內(nèi)部功能模塊的劃分以及各模塊功能介紹、相互之間的關(guān)系表述；
• 接口設(shè)計(jì)：包括系統(tǒng)間的接口設(shè)計(jì)以及內(nèi)部功能模塊之間的接口設(shè)計(jì)；
• 數(shù)據(jù)架構(gòu)：本系統(tǒng)與上下游系統(tǒng)間的數(shù)據(jù)流關(guān)系，以及本系統(tǒng)關(guān)鍵數(shù)據(jù)表設(shè)計(jì)、數(shù)據(jù)管理策略等；
• 技術(shù)架構(gòu)：實(shí)施此架構(gòu)需要用到哪些技術(shù)能力，有哪些復(fù)用能力及風(fēng)險(xiǎn)；
• 部署架構(gòu)：系統(tǒng)如何部署，網(wǎng)絡(luò)拓?fù)渖嫌泻我?，?duì)硬件服務(wù)器有何要求，需要幾臺(tái)，是否需要優(yōu)化服務(wù)器參數(shù)；
• 非功能性設(shè)計(jì)：性能、高可用、可擴(kuò)展性、可維護(hù)、安全性、可移植性等。
• 其他說明：如特別約束條件、風(fēng)險(xiǎn)考慮、進(jìn)度要求、政策限制、環(huán)境影響等；

那么我們依次來看，每個(gè)章節(jié)在評(píng)審過程中需要關(guān)注哪些問題，編寫架構(gòu)設(shè)計(jì)說明書的人員有針對(duì)性的需要提供哪些內(nèi)容：

（一）文檔概述

對(duì)本架構(gòu)設(shè)計(jì)說明書本身進(jìn)行解釋，需要說明清楚本文檔背景，即為什么有這個(gè)文檔，文檔的內(nèi)容范圍，預(yù)期的讀者，包括了哪些需要同步參考的文檔，有哪些需要說明術(shù)語等，可以分二級(jí)標(biāo)題來寫，內(nèi)容形式如：本文檔是對(duì)XX系統(tǒng)第XX期項(xiàng)目架構(gòu)設(shè)計(jì)/升級(jí)/變更進(jìn)行闡述，主要從整體架構(gòu)、邏輯架構(gòu)、接口設(shè)計(jì)。。。等等各方面詳細(xì)說明了本系統(tǒng)各架構(gòu)維度的內(nèi)容，期望讀者為項(xiàng)目管理人員、架構(gòu)管理人員、運(yùn)維人員等，在編制過程中參考了XX需求書、XX架構(gòu)設(shè)計(jì)規(guī)范等；評(píng)審一般會(huì)關(guān)注：   

文檔目的及內(nèi)容范圍是否是從架構(gòu)角度來說明的；

參考文檔否則提到了《用戶需求規(guī)格說明書》、業(yè)務(wù)知識(shí)文檔等；

說明術(shù)語是否對(duì)非通用和非IT縮寫進(jìn)行了解釋；

整章是否交代清楚了文檔整體上的介紹，使讀者對(duì)全篇有了大致的了解。

（二）整體架構(gòu)

描寫系統(tǒng)在架構(gòu)設(shè)計(jì)時(shí)總體的思路及方針，比如采取了分層架構(gòu)、B/S架構(gòu)、服務(wù)化、數(shù)據(jù)分離等，同時(shí)在設(shè)計(jì)過程中的一些約束條件，如網(wǎng)絡(luò)訪問約束、開發(fā)規(guī)范約束、開源產(chǎn)品協(xié)議類型等，更重要的是，作為整體架構(gòu)，一定要將本系統(tǒng)作為一個(gè)內(nèi)部不透明的整體，闡述清楚與之有交互的外部系統(tǒng)都有哪些，與具體外部系統(tǒng)的交互實(shí)現(xiàn)的需求是什么？如通過消息總線獲取客戶信息，通過企業(yè)內(nèi)容管理存取非結(jié)構(gòu)化數(shù)據(jù)，通過CRM獲取客戶信息等，并以本系統(tǒng)為中心描繪整個(gè)交互關(guān)系圖，也就是整體架構(gòu)圖。評(píng)審一般會(huì)關(guān)注： 

設(shè)計(jì)方案表述是否清晰并與實(shí)際設(shè)計(jì)內(nèi)容一致；

相應(yīng)的約束是否真實(shí)具體，有可檢查性；

從整體架構(gòu)圖是否能看清這個(gè)系統(tǒng)需要和哪些系統(tǒng)交互，交互的目的是什么；

對(duì)于系統(tǒng)間的交互是否正確，外部系統(tǒng)是否能滿足交互，如通過CRM獲取客戶信息可以，獲取機(jī)構(gòu)信息可行嗎。

（三）邏輯架構(gòu)

邏輯架構(gòu)關(guān)心的是如何將系統(tǒng)分為不同部分以及各部分之間如何交互，其規(guī)定了軟件系統(tǒng)由哪些邏輯元素組成以及這些邏輯元素之間的關(guān)系（層、子系統(tǒng)、模塊等的劃分決定+交互接口和交互機(jī)制[方法調(diào)用、RMI、消息]），因此邏輯架構(gòu)圖需要說清楚本系統(tǒng)包含了哪幾項(xiàng)功能模塊，模塊之間如何交互，交互的目的是實(shí)現(xiàn)哪些業(yè)務(wù)需要。同時(shí)，對(duì)于具體的功能模塊，需要詳細(xì)說明清楚功能模塊的業(yè)務(wù)意義。評(píng)審一般會(huì)關(guān)注： 

 邏輯架構(gòu)圖是否列出了功能模塊，及其模塊間的交互關(guān)系；

是否對(duì)圖中列出的模塊進(jìn)行了詳細(xì)說明，使得讀者完全了解為什么會(huì)有此功能模塊，它包括了哪些業(yè)務(wù)需求。

（四）接口設(shè)計(jì)

架構(gòu)設(shè)計(jì)中對(duì)接口的設(shè)計(jì)包括兩方面的內(nèi)容，一方面是指本系統(tǒng)與外部系統(tǒng)之間的外部接口關(guān)系，需要全部例舉所有與外部系統(tǒng)的接口，詳細(xì)解釋每一個(gè)外部接口的名稱（如XX數(shù)據(jù)推送接口）、所交互的系統(tǒng)名稱（如ODS）、交互方式（如Webservice）、交互類別（如后臺(tái)異步）、接口描述（如本系統(tǒng)通過此接口從ODS中獲取XX業(yè)務(wù)數(shù)據(jù)）；另一方面是指本系統(tǒng)內(nèi)部功能模塊之間的內(nèi)部調(diào)用關(guān)系，嚴(yán)格意義說來說這部分屬于邏輯架構(gòu)的一部分，同樣需要根據(jù)各功能模塊的調(diào)用實(shí)際全部例舉，依次解釋每個(gè)內(nèi)部接口的名稱（如報(bào)表服務(wù)接口）、主調(diào)模塊（即主動(dòng)發(fā)起內(nèi)部調(diào)用的功能模塊如展示模塊）、服務(wù)模塊（即提供服務(wù)的模塊，如報(bào)表模塊）、接口描述（如展示模塊通過此接口從報(bào)表模塊獲取報(bào)表數(shù)據(jù)從而實(shí)現(xiàn)模塊間的解耦），一般來說內(nèi)部接口調(diào)用屬于代碼級(jí)，如果對(duì)于需要獨(dú)立部署的模塊而使用遠(yuǎn)程調(diào)用方式的，需要做特別說明。接口是系統(tǒng)復(fù)雜度的一種體現(xiàn)，是體現(xiàn)高內(nèi)聚、低耦合設(shè)計(jì)原則一個(gè)很重要的方面，評(píng)審一般會(huì)關(guān)注：

外、內(nèi)部接口是否全部例舉，是否按照上述對(duì)接口各維度的要素進(jìn)行了解釋說明；

對(duì)于服務(wù)方，是否確實(shí)能按照接口所描述的提供相應(yīng)的服務(wù)。

（五）數(shù)據(jù)架構(gòu)

數(shù)據(jù)處理是系統(tǒng)的***目標(biāo)，系統(tǒng)在處理過程中有可能需要外部數(shù)據(jù)的協(xié)助，同時(shí)系統(tǒng)處理完數(shù)據(jù)后也可能需要提供給其他系統(tǒng)使用，因此對(duì)于數(shù)據(jù)架構(gòu)最重要的是講清楚本系統(tǒng)處理的數(shù)據(jù)在整個(gè)業(yè)務(wù)數(shù)據(jù)流鏈條上的位置，上游有哪些系統(tǒng)為本系統(tǒng)供數(shù)，下游哪些系統(tǒng)需要使用本系統(tǒng)的數(shù)據(jù)。另外，針對(duì)系統(tǒng)對(duì)數(shù)據(jù)的處理，需要解釋系統(tǒng)設(shè)計(jì)了哪些關(guān)鍵表，數(shù)據(jù)初始化采用何種方式、數(shù)據(jù)冗余如何做，備份如何做等，評(píng)審一般會(huì)關(guān)注：

是否從業(yè)務(wù)數(shù)據(jù)流向角度描述清楚了本系統(tǒng)數(shù)據(jù)與上下游系統(tǒng)數(shù)據(jù)之間的關(guān)系；

針對(duì)本系統(tǒng)承載的業(yè)務(wù)處理，設(shè)計(jì)了哪些關(guān)鍵實(shí)體數(shù)據(jù)表及其對(duì)應(yīng)，是否能全面覆蓋；

有無本系統(tǒng)產(chǎn)生的數(shù)據(jù)體量估算、數(shù)據(jù)初始化、數(shù)據(jù)歸檔方式、備份策略等。

（六）技術(shù)架構(gòu)

從技術(shù)的角度描述本系統(tǒng)在實(shí)現(xiàn)過程中用到的關(guān)鍵技術(shù)能力，核心的技術(shù)組件，包括成熟商業(yè)套件以及開源的技術(shù)產(chǎn)品。如果是商業(yè)套件需要說明使用限制，升級(jí)支持等，如果是開源技術(shù)需要說明開源協(xié)議要求等?？梢园捶謱蛹軜?gòu)的模式，比如展現(xiàn)層用到了JQuery、Flex之類的，邏輯控制層用到了spring、json等，這個(gè)一定是從技術(shù)上來說的，對(duì)于具體用到的組件，一定要說明組件的版本、功能、適用場景呢。當(dāng)然，可復(fù)用性是技術(shù)架構(gòu)的關(guān)鍵，無論是使用之前的組件還是開源產(chǎn)品，都是通過可復(fù)用性來減少資源重復(fù)投入，因此在技術(shù)組件中需要強(qiáng)調(diào)對(duì)可復(fù)用性的重視，評(píng)審一般會(huì)關(guān)注：

是否對(duì)關(guān)鍵技術(shù)進(jìn)行了說明，且能明確表述此技術(shù)的成熟度與適用性；

對(duì)某些技術(shù)的使用是否與企業(yè)通用的同類技術(shù)有沖突，比如企業(yè)內(nèi)其他系統(tǒng)多使用redis，而本系統(tǒng)確使用memcached；

（七）部署架構(gòu)

講清楚系統(tǒng)分為了幾個(gè)物理部分，每部分需要幾臺(tái)服務(wù)器，服務(wù)器之間是共同提供服務(wù)的集群模式還是一臺(tái)提供服務(wù)一臺(tái)備用的Master-Slave模式，或者是一臺(tái)負(fù)責(zé)寫多臺(tái)多臺(tái)負(fù)責(zé)讀的讀寫分離模式，從網(wǎng)絡(luò)層面來看，系統(tǒng)處于整個(gè)企業(yè)網(wǎng)絡(luò)環(huán)境的哪個(gè)位置如外聯(lián)區(qū)或DMZ區(qū)或內(nèi)網(wǎng)區(qū)等。對(duì)于需要的服務(wù)器，需要說明服務(wù)器的軟硬件配置信息，如硬件方面幾核多大內(nèi)存、硬盤大小、網(wǎng)絡(luò)端口數(shù)及網(wǎng)絡(luò)帶寬要求，軟件方面對(duì)操作系統(tǒng)的要求，版本要求，系統(tǒng)及軟件參數(shù)的調(diào)優(yōu)設(shè)置等；是否需要預(yù)安裝第三方軟件，所需軟件的版本、部署說明等。評(píng)審一般會(huì)關(guān)注：

是否能從部署架構(gòu)圖看明白系統(tǒng)分幾部分進(jìn)行物理部署;

各部署部分之間的服務(wù)器的協(xié)作關(guān)系；

對(duì)硬件服務(wù)器的型號(hào)、配置、數(shù)量等是否明確；

整體部署的網(wǎng)絡(luò)區(qū)域是否明確；

是否需要對(duì)相關(guān)參數(shù)的調(diào)優(yōu)及特殊部署要求進(jìn)行了說明。

（八）非功能性說明

系統(tǒng)的非功能性包括性能、高可用、可擴(kuò)展性、可維護(hù)、安全性、可移植性，一般來說，對(duì)于性能或安全性有較高要求的系統(tǒng)，可以將其獨(dú)立成一個(gè)一級(jí)章節(jié)來寫，比如實(shí)時(shí)分析類系統(tǒng)要求性能，交易類要求安全，可以將性能和安全作為獨(dú)立的章節(jié)來描述，其他非功能性也可以類似處理。在編寫過程中，可以有主次的分別進(jìn)行闡述，但一定要從系統(tǒng)的實(shí)現(xiàn)性來說，即需要描述清楚系統(tǒng)做了何種設(shè)計(jì)或優(yōu)化以滿足性能，設(shè)計(jì)了何種校驗(yàn)機(jī)制來保障安全，如何通過集群或熱備部署來保證可用性，如何講過去狀態(tài)化實(shí)現(xiàn)可擴(kuò)展等，這些設(shè)計(jì)是如何落實(shí)在系統(tǒng)里的。即要從系統(tǒng)如何做來滿足非功能性的角度，而不是解釋具體的非功能性要求是什么。評(píng)審一般會(huì)關(guān)注：

對(duì)非功能性的描述是從系統(tǒng)如何實(shí)現(xiàn)而不是對(duì)系統(tǒng)的要求角度來說的；

每類非功能性都能從需求里面找到對(duì)應(yīng)的需求點(diǎn)，且與業(yè)務(wù)實(shí)際相匹配；

系統(tǒng)對(duì)非功能性的實(shí)現(xiàn)與系統(tǒng)本身的架構(gòu)不矛盾，架構(gòu)可以通過合理的調(diào)整來滿足；

非功能性的評(píng)審需要根據(jù)不同系統(tǒng)的業(yè)務(wù)特點(diǎn)來評(píng)審，總體的編制原則是說實(shí)現(xiàn)不說需求，畢竟架構(gòu)設(shè)計(jì)是要指導(dǎo)后續(xù)系統(tǒng)建設(shè)實(shí)施的。

（九）其他說明

此章節(jié)主要對(duì)一些輔助的約束或環(huán)境進(jìn)行說明，如約束條件、風(fēng)險(xiǎn)考慮、進(jìn)度要求、政策限制、環(huán)境影響等，根據(jù)實(shí)際可預(yù)見的情況編寫即可。如高層對(duì)系統(tǒng)總體的要求、開發(fā)資源的限制、業(yè)務(wù)環(huán)境的影響、人員知識(shí)結(jié)構(gòu)等。評(píng)審過程一般不關(guān)注具體事項(xiàng)，除非系統(tǒng)有特別要求。

以上就是整個(gè)架構(gòu)設(shè)計(jì)說明書的評(píng)審內(nèi)容，也是各章節(jié)編制的指導(dǎo)思路，本人根據(jù)在實(shí)際工作中的一些體會(huì)粗略總結(jié)，不一定全面，但是對(duì)整個(gè)編制會(huì)有一些幫助，和大家一起討論學(xué)習(xí)。