自從5月8號寫完架構設計三部曲的***部如何寫架構設計說明書，到現在快20多天了，這段時間主要準備了下系統分析師的考試，當然還有各種工作上的雜事，于是也就拖到現在寫第二部如何評審架構設計說明書。當然這個是從評審的角度來看的，其實從編制架構設計說明書的角度來看，也可以闡述具體如何編寫架構設計說明書，就像高考作文一樣，評審總是有些采分點的嘛，那么對于編制架構設計說明書來說，哪些是我們應該準備的采分點呢？我們在編制的過程中需要重點注意哪些章節的哪些內容呢？這就是我接下來想和大家分享的。

[[135498]]

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

• 文檔概述：包含項目背景、項目目標、文檔版本信息、目標讀者、參考文檔、名詞解釋之類的一般文檔都會有的章節；
• 整體架構：主要從整個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區或內網區等。對于需要的服務器，需要說明服務器的軟硬件配置信息，如硬件方面幾核多大內存、硬盤大小、網絡端口數及網絡帶寬要求，軟件方面對操作系統的要求，版本要求，系統及軟件參數的調優設置等；是否需要預安裝第三方軟件，所需軟件的版本、部署說明等。評審一般會關注：

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

各部署部分之間的服務器的協作關系；

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

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

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

（八）非功能性說明

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

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

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

系統對非功能性的實現與系統本身的架構不矛盾，架構可以通過合理的調整來滿足；

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

（九）其他說明

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

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