軟件架構設計說明書該怎麼寫?

點擊上方藍字,關注我們




背景


架構設計不是架構師的專屬工作,對非技術人員甚至是開發人員來說,從實實在在的需求到高神莫測的架構設計彷彿是一個神祕的過程,
只有具有架構師頭銜的人才能掌握各中玄妙,這篇文章就是從最基本的事物關係來回答如何根據需求進行架構設計的問題。
根據我前面的文章,架構的本質是事物與事物之間恰當的關係,不同領域的架構,其事物的指代不同,
比如對於組織架構而言,事物指的是人與機構;建築架構,事物指的是鋼筋混凝土與空間。
那在軟件領域,事物指的是什麼呢?
我們知道,軟件系統的本質是人類將自身無法處理的大量業務相關的數據進行篩選分類,並轉換成計算機可以識別的格式,藉助其強大計算能力來輔助處理。
因此在軟件領域,架構中的事物指的是業務數據與基於運算能力的業務邏輯,說的再寬泛一點就是數據與處理數據的計算能力。
那麼,架構設計其本質就是尋找數據、計算以及它們之間的平衡關係,這裏麪包括三個方面的要素,即數據、計算、平衡關係
其中數據和計算是架構設計的基礎,根據實際業務需求一般不難找出,而平衡關係是綜合考慮多方面得到的一種狀態,也是衡量一個架構設計優劣的核心要素。


需求



1.數據


在對一個系統進行架構設計時,首先我們需要做的就是依據本系統所承載的業務需求,找出需要處理的最重要或最核心的數據,
這些數據一般隱藏在線下的紙質材料裏,或者記錄在日常辦公的筆記裏,或是約定俗成的共同認識,只要從實際業務出發,找這些數據並不難。
如果你無從下手,這裏有個小竅門可以利用,
找一個出現率很高的業務,在該業務處理前儘可能多的記錄一些可能與該業務相關的數據狀態,待業務處理完成後,再次記錄,並與之前的數據進行比較,
那些發生了變化的往往就是我們需要重點關注的重要數據。
舉例來說:
  • 如果這是一個政府行政辦公的系統,那麼辦公流轉過程就是數據,每個環節辦理狀態就是數據;
  • 如果這是銀行信用卡管理系統,那麼用戶信用卡可用金額、賬單、有效期等狀態信息就是數據,每筆刷卡流水就是數據;
  • 如果這是電子商務系統,那麼商品信息、用戶訂單、購物車信息就是數據。。。等等,
所有那些在實際業務過程中會變化的,並且是與該業務緊密相關的數據,都是我們需要找到的數據,
在所有已經找到的數據中,再依據實際業務的重要程度,找出最重要最核心的數據,作爲在架構設計中我們需要重點處理的對象,
其他次重要的數據在覈心數據充分處理的前提下作爲平衡關係的備用因素。


2.計算


重要數據找到後我們還需要確定如何處理這些數據,即計算,說的明白一點就是計算邏輯是什麼,計算邏輯類似但並不完全等同於業務邏輯,
它是業務邏輯在計算機世界裏的一種體現,業務邏輯在真實世界裏需要考慮人、時間、空間的因素,而計算邏輯在計算機的世界裏,
是二進制碼、CPU、內存、存儲、網絡等因素,
還是以上面的例子來說:
  • 政府行政辦公系統需要將線下的紙質簽字蓋章從發起請求到辦結的全過程搬移到線上由系統處理,
    那就需要轉化成線上的在線申請、辦理、流轉、通知、辦結、存檔等過程,這些過程在線下可能有不同的部門來負責,
    但是線上將由我們設計的系統完全支撐;
  • 對於銀行信用卡管理系統,需要將銀行對信用卡的管理業務轉化成具體的設置或查詢可用金額、賬單、有效期等信息的功能,
    還有記錄和統計用戶消費流水等,如果業務有需求,甚至需要根據用戶的消費流水對用戶畫像,以便進行精準營銷等所謂的大數據分析模塊;
  • 電子商務系統也是一樣,需要系統提供向用戶展示商品信息,記錄用戶點擊購買後的購物車信息,創建或更新用戶的訂單信息,
    以及跟蹤訂單從倉庫打包到送達的物流信息。。。等等,
這些都是我們對數據進行的動作,而動作不是我們憑空想象出來的,是從實際的業務處理轉化到計算機領域而來的,
在轉化的過程中我們需要時刻對應現實中的處理動作如何轉換成計算機世界裏的處理數據的能力。
由於尋找計算是一種業務動作的轉化,在轉化時我們可以多問自己期望系統應該如何幫我更好的處理數據,
那些利用機器能很好的完成而人工較難做到的但又是經常需要做的且與業務相關的動作一般都是我們需要找的,
常見的動作有:
  • 數據跟蹤記錄、
  • 查詢統計、
  • 修改更新、
  • 導出展現、
  • 彙總分析等。
當然有一點需要注意,我們在尋找計算因素的時候一定要基於計算機世界的客觀現實,畢竟計算機不是萬能的。


3.關係


明確了數據及如何處理數據,架構設計接下來要做的就是如何平衡好各種相互影響的關係,這些關係是所有我們能想到的會影響到系統的矛盾體,
  • 數據處理效率與處理能力的關係、
  • 數據體量與存儲能力的關係、
  • 數據展現與用戶要求的關係、
  • 系統部署與網絡環境的關係、
  • 系統建設與建設成本的關係、
  • 系統易用性與客戶要求的關係等等,
在做架構設計的時候要儘可能多的考慮到這些關係,並根據實際情況劃分關係的重要程度,重點保障那些重要性高的關係,
畢竟再完美的架構設計也無法平衡好所有的關係,從這個角度來說,架構設計是一種平衡的藝術。
當然,要準確找出這些關係,並對它們劃分重要性等級,還需要做到按等級進行平衡是需要經驗積累的,非一朝一夕之功,
這也是人人都能做架構設計,但不是人人都能做好架構設計的原因。好在這一步並不是完全無規律可循的,
首先我們講如何找出這些關係,雖然涉及影響一個系統的矛盾體很多,
但是大致上我們可以從以下3個方向來挖掘出這些關係:

1. 與人相關的:

這裏的人包括籌建系統的甲方、建設系統的乙方、以及使用系統的用戶,
- 對於籌建系統的甲方來說,他一般關注系統的建設進度、成本、質量等,
- 對於建設系統的乙方來說,重點會關注建設範圍、風險、開發工具、實施環境等,
- 對於用戶來說,更關係系統易用性、界面友好,操作舒暢、能幫其解決實際問題等。
涉及到與人相關的關係,除了從經驗中獲取,更重要的是需要在前期系統設計的過程中通過調研的方式,
多與相關的干係人溝通,從他們那裏獲取,這也是爲什麼系統建設一般都是有需求調研過程的原因。
針對與人相關的關係這部分設計內容一般體現在架構設計說明書中的概述裏,包括項目目標、項目背景及其他說明等,
當然與用戶相關的一般也會在非功能性上有所體現,如易用性、可用性、安全等;

2. 與外部系統相關的:

主要指其運行所在的操作系統及服務器,以及與之交互的外部系統,系統需要運行在服務器特定的操作系統上,受服務器操作系統計算存儲網絡等因素影響,
需要考慮服務器計算能力是否能處理數據、存儲能力是否足夠、網絡是否穩定、如果服務器計算存儲網絡能力不夠如何擴展等;
與外部系統的交互方面,本系統需要從外部系統獲取哪些數據與能力、需要爲外部系統提供哪些數據與能力、交互方式是什麼、交互協議如何等。
    一般來說,服務器的能力總是會有不夠的,尤其是設計大數據量處理,大量用戶同時訪問的系統時,
這就需要我們根據系統的特點提前做好擴展的設計,高併發處理、分佈式理論、多機房部署等這些技術概念可以給我們很好的指引,
這也是爲什麼架構師一定要眼界開闊的原因。
這部分的設計內容一般體現在架構設計說明書中的
  • 邏輯架構、
  • 技術架構、
  • 接口設計、
  • 部署架構、
  • 性能、
  • 可維護、
  • 可擴展等非功能性設計上

3. 與數據相關的:

數據是系統處理的主體,需要劃分本系統所處理的數據與外部數據的邊界,明確與外部數據的流向關係,
還需要根據實際業務來區分數據內部之間的關係,數據如何劃分、各部分數據的邊界在哪、與整體數據的關係如何等等。
在劃分與外部數據的邊界時要基於本系統所承載的實際業務內容,從業務出發,那些只受本業務影響的數據肯定在邊界內,
而本業務與其他業務共同影響的還需要進一步分析哪方是影響主體,如果本業務是影響主體,那麼在邊界內,但是需要考慮提供給外部系統的交互接口,
如果本業務非影響主體,那麼再看是否有間接影響或關聯影響,一般來說這部分數據都要考慮與外部系統的交互關係。
對於邊界內的數據關係也是如此,可以根據業務特點劃分一些區塊,每個區塊內又是一個相對獨立的單元,
與相關的其他區塊單元存在哪些數據上的直接或間接影響,他們之間如何交互等。所有這些關係都是我們需要發現並在架構設計時考慮的。
針對這部分的設計內容一般體現在架構設計說明書中的數據架構、整體架構裏。
人、外部系統、數據是我們在發掘關係時可以參考的方向,根據系統各自的特點,在架構設計過程中還會有一些需要實際去考慮的關係,
這些關係一般都是所謂的系統最大的特點或特殊情況,常見於重大需求,特色需求,亮點需求等形式,一般也不難找出。
待把所有這些關係找出後,可以先做一個粗略的重要性分級,分級的依據是關係的相關性,
重要需求相關>特色亮點需求>甲方相關>用戶相關>乙方相關>外部系統相關>外部數據相關>內部數據相關>其他次重要的數據,
在進行架構設計時優先滿足重要性高的關係,得出一個基本的架構雛形,再根據弱一級的關係不斷地優化完善架構模型,
待大部分關係都可以滿足後,架構設計也就出來了。
當然,很多關係之間都是矛盾的,
比如:
  • 籌建系統的甲方要求的低成本與高質量、
  • 系統間數據交互與操作舒暢等,
需要我們在做架構設計時不斷權衡,儘可能的兼顧,對於實在無法兼顧的,需要進行權衡取捨。
綜上來說,架構設計就是一個找準數據主體、明確處理邏輯、平衡矛盾關係的過程
需要根據實際業務進行適當的抽象,使之適合體現在計算機的世界,每一步都需要我們明確主體,分清主次,並儘可能的平衡更多的關係,
這需要不斷的積累經驗,也靠一點悟性,有時候也需要一些靈感。
無論如何,架構設計都不只是架構師的工作,而是任何人都可以做的一項有趣的工作,
願你看完此篇文章後對架構設計不再迷茫,逐步成爲一個優秀的架構師。


技術評審提綱


業務項目千差萬別,沒有一個統一的方法論完成架構設計和技術評審,架構設計只需要從某些關鍵點來表達系統即可,
提綱就是用來幫助大家做架構評審的工具,幫助大家整理思路並形成可實施的方案,
因此在做系統設計時,可有選擇性的參考此提綱,根據業務特點來完成一個可實現的有效的架構設計。

現狀

業務背景
  • 項目名稱
  • 業務描述
技術背景
  • 架構描述
  • 當前系統容量(系統調用量平均值)
  • 當前系統調用量峯值

需求

業務需求
  • 要改造的需求
  • 要實現的需求
性能需求
  • 預估系統容量(預估系統調用量平均值)
  • 預估系統調用量峯值
  • 其他非功能質量

方案描述

方案1:

  • 概述
一句話概括方案的亮點,比如說: 雙寫,主從分離,分庫分表,擴容,歸檔等。
  • 詳細說明
方案的具體描述,文字描述不清楚的話可以結合圖(任何圖:UML,概念圖,框圖等)的方式說明,
如果是改造方案最好突出變動的地方,以下列舉了幾種描述的角度:

* 中間件架構(應用服務器、數據庫、緩存、消息隊列等)
* 邏輯架構(模塊劃分、模塊通信、信息流、時序等)
* 數據架構(數據結構、數據分佈、拆分策略、緩存策略、讀寫分離策略、查詢策略、數據一致性策略)
* 異常處理,容災策略,灰度發佈
  • 性能評估
給出方案的基準數據,並按性能需求評估需要使用的資源數量。

單機併發量
單機容量
按照預估性能需求,預估資源數量(應用服務器、緩存、存儲、隊列等)
伸縮方式
  • 方案優缺點
列出方案的優缺點,優缺點要具有確定性,不要有“存在一定風險”這種描述,也就是要量化。

方案2:

等等

方案對比

對比可選方案,並給出選擇這種方案的理由,選擇傾向的方案,

風險評估

標識所選方案的風險,提出解決此風險發生時候的應對策略,比如:上線失敗時的回滾策略。

工作量評估

描述使用所選方案需要做的具體工作,並評估開發、測試等細化任務需要的時間,形成可實施的任務計劃表,
任務計劃表推薦採用簡單的表格形式,減少工具使用和學習的成本。

性能和容量評估案例

背景

物流系統包含如下兩個質量優先需求:
  • 維護會員常用地址,下單時提供會員地址列表。
  • 下單時異步產生物流訂單,物流系統後臺任務從第三方物流輪循拉取物流狀態,已經下單用戶查詢訂單的物流訂單和物流記錄。
由於會員數量較大,可能有較快的增長速度,訂單數量更是巨大,促銷期峯值的訂單產生量可能很高,這兩個業務模塊的數據存儲需要分庫分表,
並藉助消息隊列和緩存抗寫和讀的流量,因此,本方案主要涉及這兩個業務的容量評估。

目標數據量級

選取行業內一線電商平臺的量級作爲目標:
  • 會員量2億,平均增長5萬/天。
  • 平時訂單量400萬/天,所有訂單下單時段集中在9:00-23:00,促銷日訂單量1400萬/天,50%訂單下單時段集中在晚上7:30-8:30和晚上22:00-23:00。

量級評估標準

  • 通用標準
    • 容量按照峯值5倍冗餘計算。
    • 會員常用地址容量按照30年計算,而物流訂單時效性較強按照3年計算。
    • 第三方查詢接口5000 QPS。
  • Mysql
    • 單端口讀:1000 QPS
    • 單端口寫:700 TPS
    • 單表容量:5000萬條
  • Redis
    • 單端口讀:4萬 QPS
    • 單端口寫:4萬 TPS
    • 單端口內存容量:32G
  • Kafka
    • 單機讀:3萬 QPS
    • 單機寫:5000 TPS
  • 應用服務器
    • 請求量每秒峯值:5000 QPS

方案

方案1:最大性能方案

由於整個電商網站剛剛上線,數據量級還無法清晰的確定,我們根據行業內知名電商當前數據量級設計最大性能方案,
本方案可以應對行業內電商巨頭的各種促銷所帶來的服務請求峯值,並且擁有最快的響應時間,達到服務性能的最大化。
需求1. 會員常用地址
  • 提供Restful服務增加會員常用地址。
  • 提供Restful服務獲取會員常用地址列表。

數據庫資源評估:


讀QPS:
會員每次下單,拉取一次會員地址列表,按照促銷日訂單量1400萬/天,50%訂單下單時段集中在兩個小時內計算:
(1400萬 × 0.5) / (2 × 60 × 60) = 1000/秒
容量評估按照5倍冗餘計算,讀QPS峯值1000/秒 * 5 = 5000/秒,需要5端口數據庫服務讀。
寫TPS:
假設每天增加的會員全部添加一次常用地址,並且高峯期會員下訂單時有20%的會員會增加一條常用地址:
(1400萬 × 0.2 + 5萬) / (2 × 60 × 60) = 400/秒
容量評估按照5倍冗餘計算,400/秒 * 5 = 2000/秒,需要3端口數據庫服務寫。
數據容量
當前有2億會員,每天增長5萬會員,平均每個會員有5個常用地址,30年會員常用地址表數量計算:
2億 + 5萬 × 365 × 30年) × 5 = 35
容量評估按照5倍冗餘計算,35億 * 5 = 175億,需要350張表即可容納。
根據以上讀QPS、寫TPS的評估,如果讀寫混布我們共需要8端口,可以使用8主8備,
如果讀寫分離,我們需要做主從部署,需要3主6從,與2倍數對齊,使用4主8從即可。
根據表容量,需要350張表,和2的指數對齊,選擇512張表,上面計算需要主庫端口爲4,
考慮到將來端口擴展不用拆分數據庫,儘量設計更多的庫,使用32個庫。
設計結果:4端口 × 32庫 × 4表, 48
緩存資源預估
爲了提高用戶下單的體驗,需要使用Redis緩存活躍用戶的常用地址。
定義當天下訂單的會員爲活躍會員,活躍會員的地址緩存24小時,
假定每天下訂單的會員均爲不同會員,每個會員有5個常用地址,緩存大小計算如下:
1400萬 × 5 × 1k = 70G
容量評估按照5倍冗餘計算,70G×5=350G,按照每臺Redis 32G內存計算,需要11臺機器,
根據數據庫對數據存取QPS/TPS的設計,11臺機器完全可以滿足5000/秒的讀QPS和2000/秒的寫TPS。
設計結果:11臺,主從
應用服務器資源評估
根據數據庫的讀QPS(5000/s)峯值和寫TPS(2000/s)峯值計算,單臺應用服務器即可,選擇2臺避免單點。
設計結果:2
需求2:物流訂單和物流記錄
  • 訂單提交後,通過消息隊列產生物流訂單,消息傳入物流系統,物流系統消費物流訂單消息然後入庫。
  • 後臺任務輪循未完成物流訂單,查詢第三方物流接口狀態,填寫物流記錄信息。按照每天1400萬的訂單,訂單平均3天到貨,第三方查詢接口5000 QPS,
    每次狀態查詢需要時間計算如下:1400萬 × 3 / 5000 = 8400 / 60 / 60 = 2小時,定時任務2小時查一次
  • 提供REST服務獲取物流訂單信息。
  • 提供REST服務獲取物流記錄信息。
  • 提供REST服務獲取物流訂單和物流記錄信息。

數據庫資源評估



讀QPS:
會員下單三天到貨,三天內50%客戶會查詢一次物流訂單和一次物流記錄,計算如下:
(1400萬 × 3 × 0.5) / (24 × 60 × 60) = 250/秒
容量評估按照5倍冗餘計算,2 × 250/秒 × 5倍 = 2500/秒,需要3端口數據庫服務讀。
寫TPS
會員每次下單,產生一次物流訂單,按照促銷日訂單量1400萬/天,50%訂單下單時段集中在兩個小時內計算:
(1400萬 × 0.5) / (2 × 60 × 60) = 1000/秒
按照每天1400萬的訂單,訂單平均3天到貨,每條物流訂單產生8條物流記錄,並且8條物流記錄在三天內均勻產生,物流記錄寫TPS計算如下:
1400萬 × 3 × 8 / 3 / (24 × 60 × 60) = 1200/秒
數據容量
當前2億物流訂單積累,每天增長400萬訂單,30年訂單數量計算:
2億 + 400萬 × 365天 × 3年 = 46
容量評估按照5倍冗餘計算,46億 * 5 = 230億,需要460張表即可容納, 物流記錄表是物流訂單的8倍,460 × 8 = 3680張表。
根據以上讀QPS和寫TPS,如果讀寫混布,我們共需要18端口,18主18備,如果讀寫分離,我們需要16主16從。
根據表容量,需要3680張表,和2的指數對齊,選擇4096張表,上面計算需要主庫端口爲16,考慮到將來端口擴展不用拆分數據庫,儘量設計更多的庫,使用32個庫。
設計結果:16端口 × 32庫 × 8表,1616
消息隊列資源評估
爲了讓系統能夠應對峯值的突增,採用消息隊列Kafka接收物流訂單。
根據上面對寫TPS的計算,考慮5倍冗餘後,峯值爲5000/秒,單臺Kafka和單臺處理機即可處理。
如果峯值有突增,可以增加Kafaka集羣的節點來抗寫流量,處理機根據後端入庫性能來決定。
例如寫峯值增加10倍,達到5萬/秒,需要10臺Kafka,每臺Kafka讀QPS可達3萬,理論上需要2臺處理機,然而,處理機的瓶頸是後端入庫的寫TPS,
根據上面計算,入庫的寫TPS峯值按照5000/秒設計,因此,單臺處理機即可,這個場景下會有消息的堆積,但是最終會處理完畢,達到消峯的效果。
設計結果:1臺Kafka,主從,1臺處理機
應用服務器資源評估
根據數據庫的讀QPS(2500/s)峯值和寫TPS(11000/s)峯值計算,3臺應用服務器即可。
用於查詢第三方接口的後臺任務服務器,由於受到第三方接口5000/s的QPS的限制,單臺機器即可,爲了避免單點,2臺處理機即可。
設計結果:2

方案2:最小資源方案

由於當前系統線上數據量並不多,增長量也不大,讀QPS和寫TPS單臺機器完全可以處理,暫時不考慮使用緩存和消息隊列,
但是保留使用緩存和消息隊列的接口,如果緩存和消息隊列的資源可用,可以通過開關進行切換。
當前的數據量使用單庫單表即可處理,然而,考慮到將來擴容方便,數據庫端口暫時使用一個,但是保留我們在最大性能方案中對數據庫的分庫分表,
當讀QPS和寫TPS突增時,DBA可以把庫重新拆分到多個端口來抗請求流量。
因此,方案如下:
  • 需求:會員常用地址
設計結果:1端口 × 32庫 × 16表, 11
  • 需求:物流訂單和物流記錄
設計結果:1端口 × 128庫 × 32表,11

總結

  • 當前線上流量並不大,使用最小資源方案節省成本。
  • 最小資源方案充分的考慮了數據庫的分庫分表,當讀QPS和寫TPS突增時,DBA可以拆分庫到不同的端口,也就是增加端口來應對。
  • 最小資源方案在應用層設計了開關,如果性能突增可以臨時申請和開啓緩存和消息隊列。

總結內容

本文以互聯網企業重點關注的非功能質量爲主線,總結了非功能質量需求的總體目標,並針對不同的服務和資源列舉了不同的非功能質量需求,
幫助讀者在做技術評審的過程整理思路,儘量窮舉評審時關注的評審點,並隨後提供了一個簡單有效的評審提綱,
最後根據提綱實現一個互聯網容量和性能評估的經典案例,大家可以在案例中瞭解高併發互聯網系統是如何進行拆分的,以及依據哪些數據進行拆分。
由於本文的數據完全是基於筆者在某個互聯網平臺下的經驗而記錄的,並不代表可以直接應用在任何企業和平臺上,
這裏重點突出進行容量和性能評估的方法論,幫助大家整理實現高併發互聯網系統的思路。

QPS、TPS、併發用戶數、吞吐量關係


谷歌開源內部代碼評審規範


UML (統一建模語言) 各種圖總結


真實項目案例實戰—【狀態設計模式】使用場景


歡迎分享轉發,有幫助的話點個“在看”

本文分享自微信公衆號 - 俠夢的開發筆記(xmdevnote)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章