組件選型
? 為什么選 A 不選 B 呢？
? A 不是開源的，出了問題怎么辦？
? B 雖然是開源的，但是是 Erlang 寫的，公司沒人能看懂怎么辦？
? C 我看待解決的 Issues 還有很多，有沒有去了解過？
? 這個組件在性能方面你是否了解過？
? 開源的免費版本不支持集群怎么辦？
? 如果徹底要自己寫這個組件有沒有可能性
組件特別是存儲組件選型挺重要的，可以有那么幾周的時間搭一個高可用的集群，使用接近于真實的數(shù)據(jù)對組件進(jìn)行壓測。眼見為實耳聽為虛，自己通過壓測對比一下自己得出的數(shù)據(jù)和公開的數(shù)據(jù)是否有差異，如果有的話說不定還能發(fā)現(xiàn)自己使用上的一些問題。盡
量還是選用使用的人多的開源組件吧，出了問題至少 Patch 不會來的太慢。
性能
? 我們需求的 TPS、QPS 和 RT 是多少？
? 整體設(shè)計上會做到的 TPS、QPS 和 RT 是多少？
? 隨著數(shù)據(jù)量的增大系統(tǒng)性能會不會出現(xiàn)明顯問題？
? 系統(tǒng)哪個環(huán)節(jié)會是最大的瓶頸？
? 是否打算做壓力測試，壓力測試方案是怎么樣的？
? 怎么提高前端用戶的訪問流暢性？
對于重要的項目，建議做一下整體壓測，沒有經(jīng)過壓測得出來的估計的結(jié)論往
往可能是錯的，我們總以為最終會死在最后的存儲上，但是很可能早早就死在
了程序的低級錯誤上，比如在一些存儲組件的 Client 使用上，如果沒把控好最
佳實踐（把應(yīng)該作為單例使用 Clinet 每次都去創(chuàng)建一次，默認(rèn)的線程數(shù)小的可
憐應(yīng)該重新配置但是保留了默認(rèn)值），死的非常難看。
可伸縮性
每一個環(huán)節(jié)是否都是可以橫向擴(kuò)展的？
? 擴(kuò)容需要怎么做手動還是自動？
? 數(shù)據(jù)庫不能橫向擴(kuò)展怎么辦？
? 縱向擴(kuò)展有多少效果？
? 橫向擴(kuò)展是否是線性的？
? 擴(kuò)展后是否可以提高響應(yīng)速度？
靈活性
? 是否有了解過產(chǎn)品層面以后會怎么發(fā)展？
? 模塊 A 是否能拆分出去獨立為其它業(yè)務(wù)服務(wù)？
? 模塊 B 是否可以替換為另一種第三方數(shù)據(jù)源？
? 如果流程有變，需要多大的工作量來適應(yīng)？
? 業(yè)務(wù)是否可以做到可配？
可擴(kuò)展性
? 為什么 A 和 B 都有差不多的邏輯？
? 是否考慮到了 A 業(yè)務(wù)的實現(xiàn)以后還有 B 的可能性？
? 如果現(xiàn)在有兩種策略以后擴(kuò)展到了八種策略怎么做？
? 以后是否可以把這個業(yè)務(wù)的 H5 前端適配到 PC？
可靠性
? 是否架構(gòu)中有單點？
? 故障轉(zhuǎn)移是怎么實現(xiàn)的？
? 集群內(nèi)部故障轉(zhuǎn)移需要多久？
? MQ 或存儲出現(xiàn)問題的時候系統(tǒng)會怎么樣？
? MQ 或存儲出現(xiàn)問題又恢復(fù)了系統(tǒng)是否會自己恢復(fù)？
? 是否考慮過異地故障轉(zhuǎn)移的方案？
? 是否考慮過多活的方案？
? 是否有數(shù)據(jù)丟失的可能性？
? 數(shù)據(jù)丟失后是否可以恢復(fù)？
? 系統(tǒng)徹底掛了對其它業(yè)務(wù)的影響是什么？
? 系統(tǒng)徹底掛了是否可以有線下的方式走業(yè)務(wù)？
安全性
? 是否徹底避免 SQL 注入和 XSS？
? 是否做了風(fēng)控策略？
? 是否有防刷保護(hù)機(jī)制？
? 數(shù)據(jù)庫拖庫了會怎么樣？
? 是否有數(shù)據(jù)泄露的可能性？
? 數(shù)據(jù)的權(quán)限怎么控制的？
? 功能的權(quán)限是怎么控制的？
? 是否做了日志審計？
? 受到了 DDOS 攻擊怎么辦？
? 數(shù)據(jù)傳輸是否加密驗簽？
兼容性
? 老的系統(tǒng)打算怎么辦？
? 怎么進(jìn)行新老系統(tǒng)替換？
? 新老系統(tǒng)能否來回切換？
? 別的系統(tǒng)怎么連接你這套新服務(wù)？
? 上下游依賴是否梳理過，影響范圍多大？
? 上下游改造的難度怎么樣？
? 上下游改造有排期嗎？
? 上下游改造的計劃和通知時間確定了嗎？
? 使用了新的數(shù)據(jù)源數(shù)據(jù)怎么遷移？
? 使用了新的技術(shù)老項目開發(fā)能否適應(yīng)？
彈性處理
? 這個數(shù)據(jù)重復(fù)消費會怎么樣？
? 這個接口重復(fù)調(diào)用會怎么樣？
? 是否考慮了服務(wù)降級？哪些業(yè)務(wù)支持降級？
? 是否考慮了服務(wù)熔斷？熔斷后怎么處理？
? 是否考慮了服務(wù)限流？限流后客戶端表現(xiàn)怎么樣？
? 隊列爆倉會怎么樣？
? 是否考慮了隔離性？
事務(wù)性
? 這段業(yè)務(wù)由誰保證事務(wù)性？
? 數(shù)據(jù)庫事務(wù)回滾后會怎么樣？
? 服務(wù)調(diào)用了失敗怎么辦？
? 隊列補償怎么做的？
? 服務(wù)調(diào)用補償怎么做的？
? 數(shù)據(jù)補償實現(xiàn)最終一致需要多久？
? 在數(shù)據(jù)不完整的時候用戶會感知到嗎？
可測試性
? 測試環(huán)境和線上的差異多大？
? 是否支持部署多套隔離的測試環(huán)境？
? 是否打算做單元測試，覆蓋率目標(biāo)是多少？
? 測試黑盒白盒工作量的比例是怎么樣的？
? 是否支持接口層面的自動化測試？
? 是否有可能做 UI 自動化測試？
? 壓測怎么造數(shù)據(jù)？
? 是否可以在線上做壓測？
? 線上壓測怎么隔離測試數(shù)據(jù)？
? 是否有測試白名單功能？
可運維性
? 每一個組件對服務(wù)器哪方面的壓力會最大？
? 重新搭建整套系統(tǒng)最快需要多少時間？
? 系統(tǒng)是否可以完全基于源代碼構(gòu)建？
? 系統(tǒng)是否有初始化或預(yù)熱的環(huán)節(jié)？
? 系統(tǒng)里哪些環(huán)節(jié)需要人工參與？
? 數(shù)據(jù)是否需要定期歸檔處理？
? 會不會有突發(fā)的數(shù)據(jù)量業(yè)務(wù)量增大？
? 隨著時間的推移如果壓力保持不變的話系統(tǒng)需要怎么來巡檢和維護(hù)？
? 怎么在容器里進(jìn)行部署？
監(jiān)控
? 業(yè)務(wù)層面哪些指標(biāo)需要監(jiān)控和報警？
? 應(yīng)用層面系統(tǒng)內(nèi)部是否有暴露了一些指標(biāo)作監(jiān)控和報警？
? 系統(tǒng)層面使用的中間件和存儲是否有監(jiān)控報警？
? 是否所有環(huán)節(jié)都接入了全鏈路跟蹤？
? 出現(xiàn)報警的時候應(yīng)該由誰來處理？
? 每一個模塊是否有固定的主要和次要負(fù)責(zé)人？
? 有沒有可能系統(tǒng)出了問題無法通過監(jiān)控指標(biāo)體現(xiàn)？
? 哪些指標(biāo)需要上大屏由監(jiān)控進(jìn)行 7*24 監(jiān)控？
設(shè)計文檔的一些要求
1.交代背景和需求全貌
使用腦圖在技術(shù)角度給出一下自己理解的項目需求的分布。PRD
中的產(chǎn)品功能腦圖可以和這里技術(shù)角度的腦圖有差異，在說清楚需求的同時側(cè)
重技術(shù)層面，體現(xiàn)在：
可以不按照需求的功能點進(jìn)行歸類而是按照實際項目歸類，把需求列在實際的項目
下面
? 可以區(qū)分需求是自己干的還是調(diào)用外部的接口，可以在圖上以不同的形態(tài)提現(xiàn)
? 可以畫出功能之間的依賴關(guān)系，以虛線實線進(jìn)一步區(qū)分依賴的程度
? 可以在圖上體現(xiàn)需求的優(yōu)先級以及需求目前的進(jìn)展和負(fù)責(zé)人，這樣基本一個圖就可
以看清楚這個項目需要消耗多少資源需要多久可以結(jié)束
2.系統(tǒng)架構(gòu)圖
架構(gòu)圖需要傳遞清楚
下面的信息：
? 項目由哪些模塊、服務(wù)、緩存、存儲構(gòu)成，可以以不同的圖案和顏色代表不同類型
? 模塊之間的依賴關(guān)系（當(dāng)然，也可以從數(shù)據(jù)的流向角度來畫）
? 核心流程的步驟，沿著圖上的 1、2、3 基本就可以大概了解核心流程的實現(xiàn)
? 可以用大的框把組件進(jìn)行分組來描述組件的部署方式（比如相同機(jī)器上承載的組件
在一個框內(nèi)）
? 可以以邊框的虛實來分類項目內(nèi)的組件或三方組件，可以以箭頭的虛實來標(biāo)記主要
流程次要流程等等
對于復(fù)雜的項目，要畫一個圖說清楚很難，可以畫一個大的架構(gòu)圖，然后針對每一個模塊或流程再細(xì)化畫不同層次的圖。
交互時序
時序圖的表達(dá)非常重要，可以表現(xiàn)需求腦圖、架構(gòu)圖和 API 腦圖無法表現(xiàn)出來
的幾個方面，清晰展現(xiàn)了某個事情：
? 關(guān)鍵的利益關(guān)系方。這個事情由哪幾個方面構(gòu)成，可以是用戶、甲方、乙方這么來
分，也可以是用戶、APP 客戶端、服務(wù)端這么來分
? 每一方在做什么，依賴的又是什么，整個順序是怎么樣的
? 技術(shù)層面這是同步接口、還是回調(diào)、還是非技術(shù)的線下流程
? 還可以在圖上表現(xiàn)出可選邏輯，條件判斷邏輯，循環(huán)邏輯等等
對于這種時序圖，采用傳統(tǒng)的工具來畫費時費力，推薦下面兩個工具
https://www.websequencediagrams.com/和http://plantuml.com/sequence-diagram
數(shù)據(jù)庫 ER
ER 圖就是實體聯(lián)系圖。形式上我們可以在圖上表現(xiàn)幾個點：
? 實體：哪些表
? 實體上的屬性：體現(xiàn)實體之間關(guān)系以及實體業(yè)務(wù)功能的重要字段
? 聯(lián)系：實體和實體之間的關(guān)系，比如一對多，多對一還是多對多之類
? ER 圖可以以極小的空間展現(xiàn)很多信息，這樣我們可以在圖上對業(yè)務(wù)進(jìn)行分組，看到全貌
? ER 圖展現(xiàn)的是表和表之間的關(guān)系，一眼可以看出最重要核心的表是哪些
