架構設計之如何評審架構設計說明書

自從5月8號寫完架構設計三部曲的第一部如何寫架構設計說明書，到如今快20多天了，這段時間主要準備了下系統分析師的考試，固然還有各類工做上的 瑣事，因而也就拖到如今寫第二部如何評審架構設計說明書。固然這個是從評審的角度來看的，其實從編制架構設計說明書的角度來看，也能夠闡述具體如何編寫架 構設計說明書，就像高考做文同樣，評審老是有些採分點的嘛，那麼對於編制架構設計說明書來講，哪些是咱們應該準備的採分點呢？咱們在編制的過程當中須要重點 注意哪些章節的哪些內容呢？這就是我接下來想和你們分享的。

根據第一部文章咱們知道一篇架構設計說明書大體章節應該是這樣的：

• 文檔概述：包含項目背景、項目目標、文檔版本信息、目標讀者、參考文檔、名詞解釋之類的通常文檔都會有的章節；
• 總體架構：主要從整個IT層描述系統所處的位置，與周邊關聯繫統之間的調用關係；
• 邏輯架構：系統內部功能模塊的劃分以及各模塊功能介紹、相互之間的關係表述；
• 接口設計：包括系統間的接口設計以及內部功能模塊之間的接口設計；
• 數據架構：本系統與上下游系統間的數據流關係，以及本系統關鍵數據表設計、數據管理策略等；
• 技術架構：實施此架構須要用到哪些技術能力，有哪些複用能力及風險；
• 部署架構：系統如何部署，網絡拓撲上有何要求，對硬件服務器有何要求，須要幾臺，是否須要優化服務器參數；
• 非功能性設計：性能、高可用、可擴展性、可維護、安全性、可移植性等。
• 其餘說明：如特別約束條件、風險考慮、進度要求、政策限制、環境影響等；

那麼咱們依次來看，每一個章節在評審過程當中須要關注哪些問題，編寫架構設計說明書的人員有針對性的須要提供哪些內容：

（一）文檔概述

對本架構設計說明書自己進行解釋，須要說明清楚本文檔背景，即爲何有這個文檔，文檔的內容範圍，預期的讀者，包括了哪些須要同步參考的文檔，有哪 些須要說明術語等，能夠分二級標題來寫，內容形式如：本文檔是對XX系統第XX期項目架構設計/升級/變動進行闡述，主要從總體架構、邏輯架構、接口設 計。。。等等各方面詳細說明了本系統各架構維度的內容，指望讀者爲項目管理人員、架構管理人員、運維人員等，在編制過程當中參考了XX需求書、XX架構設計 規範等；評審通常會關注：   

文檔目的及內容範圍是不是從架構角度來講明的；

參考文檔不然提到了《用戶需求規格說明書》、業務知識文檔等；

說明術語是否對非通用和非IT縮寫進行了解釋；

整章是否交代清楚了文檔總體上的介紹，使讀者對全篇有了大體的瞭解。

（二）總體架構

描寫系統在架構設計時整體的思路及方針，好比採起了分層架構、B/S架構、服務化、數據分離等，同時在設計過程當中的一些約束條件，如網絡訪問約束、 開發規範約束、開源產品協議類型等，更重要的是，做爲總體架構，必定要將本系統做爲一個內部不透明的總體，闡述清楚與之有交互的外部系統都有哪些，與具體 外部系統的交互實現的需求是什麼？如經過消息總線獲取客戶信息，經過企業內容管理存取非結構化數據，經過CRM獲取客戶信息等，並以本系統爲中心描繪整個 交互關係圖，也就是總體架構圖。評審通常會關注： 

設計方案表述是否清晰並與實際設計內容一致；

相應的約束是否真實具體，有可檢查性；

從總體架構圖是否能看清這個系統須要和哪些系統交互，交互的目的是什麼；

對於系統間的交互是否正確，外部系統是否能知足交互，如經過CRM獲取客戶信息能夠，獲取機構信息可行嗎。

（三）邏輯架構

邏輯架構關心的是如何將系統分爲不一樣部分以及各部分之間如何交互，其規定了軟件系統由哪些邏輯元素組成以及這些邏輯元素之間的關係（層、子系統、模 塊等的劃分決定+交互接口和交互機制[方法調用、RMI、消息]），所以邏輯架構圖須要說清楚本系統包含了哪幾項功能模塊，模塊之間如何交互，交互的目的 是實現哪些業務須要。同時，對於具體的功能模塊，須要詳細說明清楚功能模塊的業務意義。評審通常會關注： 

邏輯架構圖是否列出了功能模塊，及其模塊間的交互關係；

是否對圖中列出的模塊進行了詳細說明，使得讀者徹底瞭解爲何會有此功能模塊，它包括了哪些業務需求。

（四）接口設計

架構設計中對接口的設計包括兩方面的內容，一方面是指本系統與外部系統之間的外部接口關係，須要所有例舉全部與外部系統的接口，詳細解釋每個外部 接口的名稱（如XX數據推送接口）、所交互的系統名稱（如ODS）、交互方式（如Webservice）、交互類別（如後臺異步）、接口描述（如本系統通 過此接口從ODS中獲取XX業務數據）；另外一方面是指本系統內部功能模塊之間的內部調用關係，嚴格意義說來講這部分屬於邏輯架構的一部分，一樣須要根據各 功能模塊的調用實際所有例舉，依次解釋每一個內部接口的名稱（如報表服務接口）、主調模塊（即主動發起內部調用的功能模塊如展現模塊）、服務模塊（即提供服 務的模塊，如報表模塊）、接口描述（如展現模塊經過此接口從報表模塊獲取報表數據從而實現模塊間的解耦），通常來講內部接口調用屬於代碼級，若是對於須要 獨立部署的模塊而使用遠程調用方式的，須要作特別說明。接口是系統複雜度的一種體現，是體現高內聚、低耦合設計原則一個很重要的方面，評審通常會關注：

外、內部接口是否所有例舉，是否按照上述對接口各維度的要素進行了解釋說明；

對於服務方，是否確實能按照接口所描述的提供相應的服務。

（五）數據架構

數據處理是系統的終極目標，系統在處理過程當中有可能須要外部數據的協助，同時系統處理完數據後也可能須要提供給其餘系統使用，所以對於數據架構最重 要的是講清楚本系統處理的數據在整個業務數據流鏈條上的位置，上游有哪些系統爲本系統供數，下游哪些系統須要使用本系統的數據。另外，針對系統對數據的處 理，須要解釋系統設計了哪些關鍵表，數據初始化採用何種方式、數據冗餘如何作，備份如何作等，評審通常會關注：

是否從業務數據流向角度描述清楚了本系統數據與上下游系統數據之間的關係；

針對本系統承載的業務處理，設計了哪些關鍵實體數據表及其對應，是否能全面覆蓋；

有無本系統產生的數據體量估算、數據初始化、數據歸檔方式、備份策略等。

（六）技術架構

從技術的角度描述本系統在實現過程當中用到的關鍵技術能力，核心的技術組件，包括成熟商業套件以及開源的技術產品。若是是商業套件須要說明使用限制， 升級支持等，若是是開源技術須要說明開源協議要求等。能夠按分層架構的模式，好比展示層用到了JQuery、Flex之類的，邏輯控制層用到了 spring、json等，這個必定是從技術上來講的，對於具體用到的組件，必定要說明組件的版本、功能、適用場景呢。固然，可複用性是技術架構的關鍵， 不管是使用以前的組件仍是開源產品，都是經過可複用性來減小資源重複投入，所以在技術組件中須要強調對可複用性的重視，評審通常會關注：

是否對關鍵技術進行了說明，且能明確表述此技術的成熟度與適用性；

對某些技術的使用是否與企業通用的同類技術有衝突，好比企業內其餘系統多使用redis，而本系統確使用memcached；

（七）部署架構

講清楚系統分爲了幾個物理部分，每部分須要幾臺服務器，服務器之間是共同提供服務的集羣模式仍是一臺提供服務一臺備用的Master-Slave模 式，或者是一臺負責寫多臺多臺負責讀的讀寫分離模式，從網絡層面來看，系統處於整個企業網絡環境的哪一個位置如外聯區或DMZ區或內網區等。對於須要的服務 器，須要說明服務器的軟硬件配置信息，如硬件方面幾核多大內存、硬盤大小、網絡端口數及網絡帶寬要求，軟件方面對操做系統的要求，版本要求，系統及軟件參 數的調優設置等；是否須要預安裝第三方軟件，所需軟件的版本、部署說明等。評審通常會關注：

是否能從部署架構圖看明白系統分幾部分進行物理部署;

各部署部分之間的服務器的協做關係；

對硬件服務器的型號、配置、數量等是否明確；

總體部署的網絡區域是否明確；

是否須要對相關參數的調優及特殊部署要求進行了說明。

（八）非功能性說明

系統的非功能性包括性能、高可用、可擴展性、可維護、安全性、可移植性，通常來講，對於性能或安全性有較高要求的系統，能夠將其獨立成一個一級章節 來寫，好比實時分析類系統要求性能，交易類要求安全，能夠將性能和安全做爲獨立的章節來描述，其餘非功能性也能夠相似處理。在編寫過程當中，能夠有主次的分 別進行闡述，但必定要從系統的實現性來講，即須要描述清楚系統作了何種設計或優化以知足性能，設計了何種校驗機制來保障安全，如何經過集羣或熱備部署來保 證可用性，如何講過去狀態化實現可擴展等，這些設計是如何落實在系統裏的。即要從系統如何作來知足非功能性的角度，而不是解釋具體的非功能性要求是什麼。 評審通常會關注：

對非功能性的描述是從系統如何實現而不是對系統的要求角度來講的；

每類非功能性都能從需求裏面找到對應的需求點，且與業務實際相匹配；

系統對非功能性的實現與系統自己的架構不矛盾，架構能夠經過合理的調整來知足；

非功能性的評審須要根據不一樣系統的業務特色來評審，整體的編制原則是說實現不說需求，畢竟架構設計是要指導後續系統建設實施的。

（九）其餘說明

此章節主要對一些輔助的約束或環境進行說明，如約束條件、風險考慮、進度要求、政策限制、環境影響等，根據實際可預見的狀況編寫便可。如高層對系統整體的要求、開發資源的限制、業務環境的影響、人員知識結構等。評審過程通常不關注具體事項，除非系統有特別要求。

以上就是整個架構設計說明書的評審內容，也是各章節編制的指導思路，本人根據在實際工做中的一些體會粗略總結，不必定全面，可是對整個編制會有一些幫助，和你們一塊兒討論學習。