朱曄的互聯網架構實踐心得S1E9：架構評審一百問和設計文檔五要素

本文我會來講說我認爲架構評審中應該看的一些點，以及我寫設計文檔的一些心得。助你在架構評審中過五關斬六將，助你寫出能讓人收藏點讚的設計文檔。

技術架構評審

架構評審或技術方案評審的價值在於集衆人的力量你們一塊兒來分析看看方案裏是否有坑，方案上線後是否會遇到不可逾越的重大技術問題，提早儘量把一些事情先考慮到提出質疑其實對項目的健康發展有很大的好處。不少公司都有架構評審委員會都有架構評審的流程，作業務的兄弟要麼看到這個流程每每心驚膽戰懼怕本身作的方案被斃了咋整，要麼就是認爲這是一種過場，隨便糊弄一點文檔發給委員會看一下就算過去了。我作過架構評審委員也作過提交評審方案的業務兄弟，無論哪一個角色我都不懼怕而是喜歡這一流程，評審這個事情作的好其實能夠很享受，你們都是一塊兒學習的過程，不存在誰爲難誰。下面說說我以爲架構評審（非代碼評審）中看重的須要評審的一些點。

組件選型

· A不是開源的，出了問題怎麼辦？

· B雖然是開源的，可是是Erlang寫的，公司沒人能看懂怎麼辦？

· C我看待解決的Issues還有不少，有沒有去了解過？

· 這個組件在性能方面你是否瞭解過？

· 開源的免費版本不支持集羣怎麼辦？

· 若是完全要本身寫這個組件有沒有可能性？

組件特別是存儲組件選型挺重要的，真心建議事先能夠有那麼幾周的時間搭一個高可用的集羣，使用接近於真實的數據對組件進行壓測（你看以前我博客上的Mongodb的壓測文章停火的，說明不少人沒有這個時間和條件對一些組件進行壓測）。眼見爲實耳聽爲虛，本身經過壓測對比一下本身得出的數據和公開的數據是否有差別，若是有的話說不定還能發現本身使用上的一些問題。儘可能仍是選用使用的人多的開源組件吧，出了問題至少Patch不會來的太慢。

性能

· 總體設計上會作到的TPS、QPS和RT是多少？

· 隨着數據量的增大系統性能會不會出現明顯問題？

· 系統哪一個環節會是最大的瓶頸？

· 是否打算作壓力測試，壓力測試方案是怎麼樣的？

· 怎麼提升前端用戶的訪問流暢性？

對於重要的項目，建議作一下總體壓測，沒有通過壓測得出來的估計的結論每每多是錯的，咱們總覺得最終會死在最後的存儲上，可是極可能早早就死在了程序的低級錯誤上，好比在一些存儲組件的Client使用上，若是沒把控好最佳實踐（把應該做爲單例使用Clinet每次都去建立一次，默認的線程數小的可憐應該從新配置可是保留了默認值），死的很是難看。

可伸縮性

· 每個環節是否都是能夠橫向擴展的？

· 擴容須要怎麼作手動仍是自動？

· 數據庫不能橫向擴展怎麼辦？

· 縱向擴展有多少效果？

· 橫向擴展是不是線性的？

· 擴展後是否能夠提升響應速度？

靈活性

· 是否有了解過產品層面之後會怎麼發展？

· 模塊A是否能拆分出去獨立爲其它業務服務？

· 模塊B是否能夠替換爲另外一種第三方數據源？

· 若是流程有變，須要多大的工做量來適應？

· 業務是否能夠作到可配？

可擴展性

· 爲何A和B都有差很少的邏輯？

· 是否考慮到了A業務的實現之後還有B的可能性？

· 若是如今有兩種策略之後擴展到了八種策略怎麼作？

· 之後是否能夠把這個業務的H5前端適配到PC？

可靠性

· 是否架構中有單點？

· 故障轉移是怎麼實現的？

· 集羣內部故障轉移須要多久？

· MQ或存儲出現問題的時候系統會怎麼樣？

· MQ或存儲出現問題又恢復了系統是否會本身恢復？

· 是否考慮過異地故障轉移的方案？

· 是否考慮過多活的方案？

· 是否有數據丟失的可能性？

· 數據丟失後是否能夠恢復？

· 系統完全掛了對其它業務的影響是什麼？

· 系統完全掛了是否能夠有線下的方式走業務？

安全性

· 是否完全避免SQL注入和XSS？

· 是否作了風控策略？

· 是否有防刷保護機制？

· 數據庫拖庫了會怎麼樣？

· 是否有數據泄露的可能性？

· 數據的權限怎麼控制的？

· 功能的權限是怎麼控制的？

· 是否作了日誌審計？

· 受到了DDOS攻擊怎麼辦？

· 數據傳輸是否加密驗籤？

兼容性

· 老的系統打算怎麼辦？

· 怎麼進行新老系統替換？

· 新老系統可否來回切換？

· 別的系統怎麼鏈接你這套新服務？

· 上下游依賴是否梳理過，影響範圍多大？

· 上下游改造的難度怎麼樣？

· 上下游改造有排期嗎？

· 上下游改造的計劃和通知時間肯定了嗎？

· 使用了新的數據源數據怎麼遷移？

· 使用了新的技術老項目開發可否適應？

彈性處理

· 這個數據重複消費會怎麼樣？

· 這個接口重複調用會怎麼樣？

· 是否考慮了服務降級？哪些業務支持降級？

· 是否考慮了服務熔斷？熔斷後怎麼處理？

· 是否考慮了服務限流？限流後客戶端表現怎麼樣？

· 隊列爆倉會怎麼樣？

· 是否考慮了隔離性？

事務性

· 這段業務由誰保證事務性？

· 數據庫事務回滾後會怎麼樣？

· 服務調用了失敗怎麼辦？

· 隊列補償怎麼作的？

· 服務調用補償怎麼作的？

· 數據補償實現最終一致須要多久？

· 在數據不完整的時候用戶會感知到嗎？

可測試性

· 測試環境和線上的差別多大？

· 是否支持部署多套隔離的測試環境？

· 是否打算作單元測試，覆蓋率目標是多少？

· 測試黑盒白盒工做量的比例是怎麼樣的？

· 是否支持接口層面的自動化測試？

· 是否有可能作UI自動化測試？

· 壓測怎麼造數據？

· 是否能夠在線上作壓測？

· 線上壓測怎麼隔離測試數據？

· 是否有測試白名單功能？

可運維性

· 每個組件對服務器哪方面的壓力會最大？

· 從新搭建整套系統最快須要多少時間？

· 系統是否能夠徹底基於源代碼構建？

· 系統是否有初始化或預熱的環節？

· 系統裏哪些環節須要人工參與？

· 數據是否須要按期歸檔處理？

· 會不會有突發的數據量業務量增大？

· 隨着時間的推移若是壓力保持不變的話系統須要怎麼來巡檢和維護？

· 怎麼在容器裏進行部署？

監控

· 業務層面哪些指標須要監控和報警？

· 應用層面系統內部是否有暴露了一些指標做監控和報警？

· 系統層面使用的中間件和存儲是否有監控報警？

· 是否全部環節都接入了全鏈路跟蹤？

· 出現報警的時候應該由誰來處理？

· 每個模塊是否有固定的主要和次要負責人？

· 有沒有可能系統出了問題沒法經過監控指標體現？

· 哪些指標須要上大屏由監控進行7*24監控？

看了這麼多問題可能會以爲這架構設計是無法作了，其實不一樣階段的項目有不一樣的目標，咱們不會在項目起步的時候作99.99%的可用性支持百萬QPS的架構，高效完成項目的業務目標也是架構考慮的因素之一。並且隨着項目的發展，隨着公司中間件和容器的標準化，不少架構的工做被標準化替代，業務代碼須要考慮架構方面伸縮性運維性等等的需求愈來愈少，慢慢的這些工做都能由架構和運維團隊來接。一開始的時候咱們能夠花一點時間來考慮這些問題，可是不是全部的問題都須要有最終的方案。

技術設計文檔

若是你在Google搜索架構設計文檔、技術設計文檔、概要設計文檔能夠搜索到不少模板，不少公司也會以這些模板做爲設計文檔的模板來讓你們填寫。對於大部分所謂的項目只是一個項目中的一個小環節是一個具體的業務邏輯，所以老是能夠看到你們寫的所謂的技術設計文檔只能填滿文檔的20%，其他都不知道怎麼寫。當你不知道文檔應該寫哪些內容的時候能夠這麼來考慮問題，就是你這個項目接下去是要賣給別人來用的，你沒有機會當面和他把這個項目說清楚，你只能經過文檔來把事情寫清楚，別人就給你一次機會，若是看不懂你文檔表達的意思，不能理解你的項目，你的項目就賣不出去不值錢，這個時候你必定會從各個角度來剖析你的系統想盡一切辦法來把事情說清楚，用這個方法逼一下本身的，你的文檔會很優秀。接下去我想說一下若是是個人話我看重技術設計的哪些部分以及這些部分的文檔的寫做方式，這些內容構成了一個必要的（概要）設計文檔，算是拋磚引玉。

交代背景和需求全貌

在這裏，推薦使用腦圖在技術角度給出一下本身理解的項目需求的分佈。PRD中的產品功能腦圖能夠和這裏技術角度的腦圖有差別，在說清楚需求的同時側重技術層面，體如今：

· 能夠不按照需求的功能點進行歸類而是按照實際項目歸類，把需求列在實際的項目下面

· 能夠區分需求是本身乾的仍是調用外部的接口，能夠在圖上以不一樣的形態提現

· 能夠畫出功能之間的依賴關係，以虛線實線進一步區分依賴的程度

· 能夠在圖上體現需求的優先級以及需求目前的進展和負責人，這樣基本一個圖就能夠看清楚這個項目須要消耗多少資源須要多久能夠結束

看了這個圖基本產品需求就能夠理解個大概，具體的細節規則能夠進一步參考PRD。

系統架構圖

在本系列文章的第二到第五篇中，我都配了一個架構圖。架構圖須要傳遞清楚下面的信息：

· 項目由哪些模塊、服務、緩存、存儲構成，能夠以不一樣的圖案和顏色表明不一樣類型

· 模塊之間的依賴關係（固然，也能夠從數據的流向角度來畫）

· 核心流程的步驟，沿着圖上的一、二、3基本就能夠大概瞭解核心流程的實現

· 能夠用大的框把組件進行分組來描述組件的部署方式（好比相同機器上承載的組件在一個框內）

· 能夠以邊框的虛實來分類項目內的組件或三方組件，能夠以箭頭的虛實來標記主要流程次要流程等等

UML裏會有一些具體的分類，什麼類圖、組件圖、部署圖等等，我以爲沒必要拘泥於這些細節，經過線線框框的架構圖能把模塊和模塊之間的關係表述請求，而後再配以必定的文字來講明每個組件便可。我本身經常使用的是gliffy，只要能說清楚，Word畫也能夠。根據項目的大小，圖上的模塊不必定是須要獨立部署的進程，模塊也能夠是項目內部的一個模塊或類。對於複雜的項目，要畫一個圖說清楚很難，能夠畫一個大的架構圖，而後針對每個模塊或流程再細化畫不一樣層次的圖。

對外API定義

API的詳細定義能夠由Swagger UI、Spring REST Doc、Miredot等等工具生成，這些生成的接口是按照代碼來組織層次關係的，只能體現接口的參數定義不能體現接口的形態等，是沒有思想的，不適合用來閱讀，只適合用來參考。所以仍是建議作一個腦圖來整體闡述一下接口的：

· 分類，按業務功能的分類，按受衆的分類等等

· 形式（圖上不一樣的顏色），同步仍是異步（結果不在響應中，單獨的回調返回），單條仍是批量，數據接口仍是頁面調用等等

· 重要性（圖上文字後的星號），好比重點標記主流程的接口

圖上能夠不顯示出參數清單，但能夠以簡單的文字來描述重要參數，好比下單接口：->@用戶身份，優惠券ID*，[{商品ID,數量}]<-訂單號，下單結果（0-失敗，1-成功）。（->表明輸入，<-表明輸出，[]表明數組，@表明隱式參數，*表明可空參數等等）。

以前強調過好屢次涉及到和外部交互的API是設計中很是重要的一個環節，不只僅體現了系統對外輸出的能力，也體現了系統設計在安全性、複用性、封裝等方面的平衡。

交互時序

時序圖的表達很是重要，能夠表現需求腦圖、架構圖和API腦圖沒法表現出來的幾個方面，清晰展示了某個事情：

· 關鍵的利益關係方。這個事情由哪幾個方面構成，能夠是用戶、甲方、乙方這麼來分，也能夠是用戶、APP客戶端、服務端這麼來分

· 每一方在作什麼，依賴的又是什麼，整個順序是怎麼樣的

· 技術層面這是同步接口、仍是回調、仍是非技術的線下流程

· 還能夠在圖上表現出可選邏輯，條件判斷邏輯，循環邏輯等等

我以爲能在比較高的層面說一下技術（對接）流程便可，不必定要詳細到類和類之間的交互，類和類之間的交互閱讀代碼或直接看全鏈路調用的圖就能夠。若是項目有多個合做方多個依賴方，項目流程比較複雜，那麼序列圖是能把這個事情說清楚的最好的方式。

對於這種時序圖，採用傳統的工具來畫費時費力，推薦下面兩個工具（www.websequencediagrams.com/和plantuml.com/sequence-di…），能夠在幾分鐘內生成須要的圖。

咱們輸入相似的文字：

title 合做流程

用戶->XX:投資YY標的

XX->YY:同步投資狀況，更新可用額度

用戶->YY:在額度內消費

YY->XX:同步消費狀況，更新可用額度，更新回款計劃

YY->XX:還款

XX->用戶:回款（已消費部分做爲手續費給XX）

opt 線下流程

XX->YY:對於YY用戶的消費出帳單

YY->XX:對帳確認帳單

XX->YY:打款開具發票

End

網站生成相似的時序圖，還能夠自由選擇本身喜歡的樣式：

數據庫ER

ER圖就是實體聯繫圖。形式上咱們能夠在圖上表現幾個點：

· 實體：哪些表

· 實體上的屬性：體現實體之間關係以及實體業務功能的重要字段

· 聯繫：實體和實體之間的關係，好比一對多，多對一仍是多對多之類

在有的時候咱們能夠省略屬性的類型定義，甚至能夠直接省略具體的屬性（實體名和M對N的關係是必須的），把圖簡化爲相似下面的部分：

ER圖的信息量很是大，絕對不是粘貼一下表結構的DDL能夠替代的，緣由是：

· ER圖能夠以極小的空間展示不少信息，這樣咱們能夠在圖上對業務進行分組，看到全貌

· ER圖展示的是表和表之間的關係，一眼能夠看出最重要核心的表是哪些

好比下圖，是否一眼就能夠看明白一套P2P金融業務整個數據結構的架構呢：

（隨便畫的圖，不表明任何意義，請不要以這個圖作P2P的表結構設計）

全部的圖，文字只是一個維度，咱們要學會利用邊框類型（矩形、圓角矩形），邊框樣式（虛線，實線），填充色，文字顏色，關聯線條粗細顏色樣式，框內ICON來增長咱們要表現信息的維度，最多能夠增長到6維+，這種能力是文字很難實現的。一圖賽過千言，因此我一直認爲圖是設計文檔中很是重要的部分。

其它

以前我說了咱們能夠以五圖的形式（需求腦圖、架構圖、API腦圖、序列圖、數據庫ER圖）把系統大概介紹一個底朝天，說清楚了需求、架構、對外接口、交互流程和數據結構設計這幾個事情，業務項目說清楚這些足夠了。

對於偏向於中間件（無論是基礎中間件仍是業務中間件，中臺）的項目（而不是業務項目），這裏我再補充幾個重要的方面，須要在設計文檔中有體現：

· 可靠性：是否有單點的組件，非單點的組件如何作故障轉移

· 高性能：是否有抗突發性能壓力的能力，大概能夠知足多少的TPS和QPS，怎麼去作來實現高性能

· 可擴展：隨着壓力上升哪些環節能夠作擴展，怎麼作擴展

· 安全性：哪些手段防突破，萬一突破了後果怎麼樣

· 兼容性：和遺留系統怎麼通信，怎麼作遷移

· …………等等方面

這些點我就不一一展開說了，在第一節說架構評審的時候都有提到過，針對那些問題寫一下本身的設計是怎麼應對的吧。

這些點我認爲能夠構成一個合格的設計文檔，文檔的形式不重要，重要的是能夠把業務的技術實現梳理清楚，確保咱們在開發以前有一個清晰的思路，在開發上線後，文檔也是一個後人熟悉系統的很是重要的手段。你可能會提出疑問說這樣的設計文檔是否是太粗略了一點，徹底沒有體現到軟件層面設計的細節，沒錯是這樣，可是我一直說的是互聯網架構心得，敢問如今互聯網項目從0開始的大項目1到2個月上線，大的版本迭代2週一次，若是設計的時間是五分之一的話，設計也就是2天到一週這樣子，咱們有多少時間和能力來細化文檔呢，若是能把我這裏說的五要素都作好，對於互聯網項目已經笑死。

還有一點每每會比較惋惜，咱們或許能夠作到在開發以前有一個概要設計文檔的產出，可是咱們很難作到在系統上線後隨着迭代還能繼續維護初版產品上線時那個大而全的文檔。隨着產品的迭代，咱們的技術文檔也像PRD迭代文檔同樣只說此次迭代的技術改動的話，這種設計文檔由於沒有全局觀意義不大。對於這個狀況，我以爲對於每一條業務線的產品，我都建議咱們至少能維護大而全的下面這些文檔的全量版本：

· 完整表結構（順帶標一下歸檔方案、重要程度）

· 需求全貌

· 對外產品能力輸出全貌

· 總體架構圖

· 關鍵業務交互流程（特別是那種很難說清楚的多方結算關係）

按期回顧一下這五個文檔，根據最近的需求改改，可能也只須要花費幾小時的時間，對於大項目其意義每每是新人的靈魂導師（以前我有畫過一個比較複雜系統的架構圖，這個架構圖我看到有人作了桌面）。