前言
架構設計是需求分析到軟件實現的橋樑，也是決定軟件質量的關鍵。編制架構設計說明書是開發人員向架構師轉變必定會經歷的過程。
承接上文：
本文來說一下如何寫架構設計說明書
需求
那麼到底如何編寫架構設計說明書？該說明書應該包括哪些方面的內容呢？我們知道，架構設計說明書是闡述系統架構具體內容的，
架構的本質是呈現三大能力：
系統如何面向最終用戶提供支撐能力
如何面向外部系統提供交互能力
如何面向企業數據提供處理能力
因此從這個角度看，對架構設計說明書的章節的設置及章節內容安排應該要能說明清楚系統架構到底是如何呈現這三種能力的，
讓我們逐個分析：
系統如何面向最終用戶提供支撐能力：
這一點是要從系統自身的能力來看，即本系統到底應該具備哪些功能，各功能間如何協作以滿足支撐最終用戶的使用，其實就是要講系統的功能架構或邏輯架構，
回答系統從功能粒度上劃分了幾個功能模塊或子系統，各模塊或子系統之間的內部接口關係如何等問題。
當然還有一個需要考慮的問題，在縱向維度上，隨着架構設計理念的不斷髮展，
邏輯架構模型從最初的展示-數據兩層模型，到展示-邏輯-數據（所謂的MVC）三層模型,甚至到展示-調用接口-邏輯-數據接口-數據五層模型，
不同層次表明系統內部設計的精細程度，因此在邏輯架構設計中也需要針對實際情況加上這種分層設計的內容。尤其是對於Browser/Server架構模式的MIS類系統，這種層次更爲常見。
另外，用戶相對於機器來說對系統提供的能力是有個人喜好要求的，不僅要求系統能提供支撐，而且還要更加穩定的、更方便的、靈活的、快速的等提供，
這就需要在架構設計說明書中增加所謂非功能性的設計，
通過參考技術評審指標，保證系統架構設計滿足用戶和系統對非功能質量的需求：
非功能質量需求的概述
核心非功能質量：
| 核心質量 | 描述 |
|---|---|
| 高性能 | 運行效率高，性價比高 |
| 可用性 | 持續可用性，縮短宕機時間，出錯恢復，可靠性 |
| 可伸縮 | 垂直伸縮，水平伸縮 |
| 可擴展 | 可插拔，組件重用 |
| 安全性 | 數據安全，加密，熔斷，防攻擊 |
其他非功能質量：
| 核心質量 | 描述 |
|---|---|
| 可監控性 | 快速發現，快速定位，快速解決 |
| 可測試性 | 可灰度，可預覽，可Mock，可拆解 |
| 魯棒性 | 容錯性，可恢復性 |
| 可維護性 | 易於維護，監控，運營，擴展 |
| 可重用性 | 可移植性，解耦 |
| 易用性 | 可操作性 |
非功能質量需求的具體指標
主要分爲4部分：應用服務器、數據庫、緩存和消息隊列。
應用服務器
應用服務器是服務的入口，請求流量從這裏進入系統，數據庫，緩存和消息隊列的訪問量取決於應用服務器的訪問量，
對應用服務器的訪問量進行評估至關重要，應用服務器主要關心每秒請求的峯值，請求響應時間等指標，
通過這些指標可以評估需要的應用服務器資源的數量
數據庫
根據應用層的訪問量和訪問峯值，計算出需要的數據庫資源的QPS，TPS，每天的數據總量等，
由此來評估所需數據庫資源的數量和配置，部署結構等。
緩存
根據應用層的訪問量和訪問峯值，通過評估熱數據佔比，計算出的緩存資源的大小，存取緩存資源的峯值，
由此來計算所需緩存資源的數量和配置，部署結構等。
消息隊列
根據應用層的訪問量和訪問峯值，計算需要消息隊列傳遞的數據內容和數據量，
計算出的消息隊列資源的數量和配置，部署結構等。
| 部署結構 | 容量與性能 | 其他 |
|---|---|---|
| 複製模型 | 每天平均數據增量 | 消費線程池模型 |
| 失效轉移 | 消息持久的過期時間 | 分片策略 |
| 持久策略 | 每秒讀峯值 | 消息的可靠投遞 |
| 每秒寫峯值 | ||
| 每條消息的大小 | ||
| 平均延遲 | ||
| 最大延遲 |
系統如何面向外部系統提供交互能力：
這一點是要把系統當成一個完整的整體，闡述它如何與外部的系統發生調用關係，外部系統爲它提供了哪些開放接口，它又爲外部系統提供了哪些外部接口和能力，
同時，在這種相互的調用關係中它處於整個IT架構的何種位置，這其實就是在說系統的整體架構。另外，如果我們把操作系統和硬件服務器也當成一類特殊的外部系統的話，
就需要說明系統如何基於操作系統利用硬件服務器來提供計算、存儲、網絡等能力，系統如何把自己拆分成不同的部分以便部署在服務器上，這其實說的是部署架構。
如何面向企業數據提供處理能力：
信息系統的原始驅動力就是人們需要藉助計算機的強大計算能力來輔助處理大量數據，從而形成可理解的信息，並最終形成可掌握的知識。
因此數據處理是系統的根本目的，至關重要，在架構設計說明書中需要單獨描述系統對數據的處理能力，即我們所謂的系統數據架構。
這還是可以從對外和對內兩個角度來看，對外即需要說明本系統處理的數據在整個企業數據流中所處的位置，與相關的上下游數據之間的關係，
本系統需要從數據上游的外部系統獲取哪些數據？又需要爲數據下游的系統提供哪些數據；對內需要說明本系統根據業務需求設計了哪些關鍵數據表，
它們之間是何種主外鍵關係，是否需要從外部導入數據爲系統做數據初始化等。當然還有對數據管理的描述，包括如何做數據冗餘設計，備份機制，數據安全管理機制等。
好，分析完這三種能力，我們幾乎就找出了架構設計說明書中應該包括的內容，包括:
整體架構、
邏輯架構、
數據架構、
部署架構、
內外部接口、
非功能性設計等，
如果純把架構設計作爲理論研究，有這些也就夠了。
但是現實中我們編制架構設計說明書畢竟是用來指導我們後續系統開發的，是需要真正落地實施的，
因此就會涉及使用何種技術實現？有哪些關鍵技術？用到了何種成熟或開源技術組件？複用了哪些之前的技術成果？等等，
同時也包括對技術風險的考慮與預防措施。所有這些就是技術架構的內容。
綜上，我們就可以得到一份完整的架構設計說明書的結構及應該包含的內容，其大致章節應該是這樣的：
文檔概述：包含項目背景、項目目標、文檔版本信息、目標讀者、參考文檔、名詞解釋之類的一般文檔都會有的章節；
整體架構：主要從整個IT層描述系統所處的位置，與周邊關聯繫統之間的調用關係；
邏輯架構：系統內部功能模塊的劃分以及各模塊功能介紹、相互之間的關係表述；
接口設計：包括系統間的接口設計以及內部功能模塊之間的接口設計；
數據架構：本系統與上下游系統間的數據流關係，以及本系統關鍵數據表設計、數據管理策略等；
技術架構：實施此架構需要用到哪些技術能力，有哪些複用能力及風險；
部署架構：系統如何部署，網絡拓撲上有何要求，對硬件服務器有何要求，需要幾臺，是否需要優化服務器參數；
非功能性設計：性能、高可用、可擴展性、可維護、安全性、可移植性等。
其他說明：如特別約束條件、風險考慮、進度要求、政策限制、環境影響等；
以上，便是我認爲一份較爲完整的架構設計說明書應該包括的內容了。
歷
史
文
章
歡迎分享轉發，有幫助的話點個“在看”
