Design Review 架構規範

Design Review 是 TTM 過程當中相當重要的一環，優秀的 Design review 不但能讓技術方案的考慮更加周全，更多意義是避免潛在的線上 Bug 以及沒必要要的反覆。

下面是我常常思考的一些問題，雖然不是每一個項目都會涉及到這些點，並且也不該該被這些問題所侷限，但做爲一個參考，依然但願能給團隊提供一個好的思考框架。

可用性

• 外部依賴有哪些？若是這些外部依賴崩潰了咱們有什麼處理措施？
• 咱們 SLA 是什麼？主要是指可用性目標幾個 9? 50/90/99 分位數的響應時間是多少？QPS 是多少？
• 咱們的超時、重試、過載保護、服務降級機制是什麼？如何避免雪崩
• 咱們的調用方有哪些？分別有什麼服務配額？是否須要對關鍵的服務調用方單獨部署？

運維

• 咱們都有配置了哪些監控？若是出現問題，咱們須要查看哪些信息？這些信息是否都有記錄？
• 報警的處理流程是什麼？
• 系統上線流程和步驟是什麼，出了問題後是否能夠回滾，以及怎麼回滾？

安全

• XSS，CSRF，SQL 注入這些是否須要處理？
• 3 防怎麼搞：防抓，防 DDOS，防惡意訪問
• 是否有請安全團隊 review
• 是否有風控的需求？
• 信息存儲時是否設計到密碼、信用卡、身份證等敏感信息，這些信息是怎麼存儲和訪問的？

擴展性

• 分層，分模塊怎麼拆分比較合理？拆分出來的模塊能夠搞成服務單獨部署嗎？
• 應用層能夠水平擴展嗎？有用 session 嗎？能夠去掉 session 嗎？
• 若是系統的負載提高到之前的 3 到 10 倍，當前系統是否依然可用
• 存儲層面若是須要擴展存儲怎麼作？
• 系統中有哪些上下依賴的節點 / 系統 / 服務？這些依賴是否會致使沒法並行開發？可否去掉這些依賴？
• 是否有數據訪問 API? 數據 API 的設計對性能的考慮是什麼？數據 API 對異常數據 (超大數據集、空數據集、錯誤數據、schema 異常...) 的處理是什麼？

存儲

• 數據計劃怎麼存儲？會有可能的性能瓶頸嗎？須要考慮一些緩存方案嗎？
• 有什麼複雜 SQL 可能會致使慢查詢嗎？
• 數據庫的操做什麼地方用了事務？什麼狀況會致使鎖競爭？咱們的鎖策略是什麼？一致性和可用性如何平衡？將來若是分庫分表會有什麼影響？
• 緩存失效會有什麼影響？緩存大量失效會有什麼影響？冷啓動有問題嗎？有熱點數據嗎？多個緩存節點須要權衡可用性和一致性嗎？
• 存儲時，是否須要分庫，分表，選擇的理由是什麼？

技術選型

• 開發語言是什麼，框架是什麼爲何用他們？
• 緩存用什麼（tair/medis/redis/memached），web server 用什麼？(nginx+php fpm/ apach php 擴展/jetty/tomcat/jboss)，消息隊列用什麼 (rebbitmq/beanstalk/kafka/mafka/metaq/notify)？爲何用它們？
• DB 是否能夠用、以及用哪一種 no sql (hbase/tair/mangodb/redis) 來優化？
• 業界或者其餘團隊是否有處理過相似問題？他們是怎麼處理的？是否能夠 copy 或者借鑑？

服務調用和服務治理

• 請求同步處理仍是異步隊列處理比較好？
• 服務接口的 URI 設計合理嗎？能夠向下兼容嗎？
• 服務間的調用協議是什麼(dubbo/hsf/thrift) ？有公司標準的調用協議能夠用嗎(hession/protobuffer)？
• 客戶端和服務端的調用協議是什麼(http/ws/私有)？有公司標準的調用協議能夠用嗎？
• 有什麼服務治理相關的要考慮的嗎？
• 可否接入 SLA 服務治理？

業務監控

• 正常的業務邏輯外，可能會有哪些奇葩或者惡意的操做？咱們應該怎麼處理？
• 除了系統上的監控外，須要什麼業務維度的監控嗎？
• log 是怎麼記的？若是要 debug 能有什麼開關迅速打開嗎？log 怎麼 rotate？log 會影響性能嗎？

複用

• 項目中有用什麼新技術嗎？爲何要用新技術？將來其餘人接手容易嗎？
• 項目中有什麼複雜計算的地方嗎？這些計算能夠用什麼算法優化嗎？
• 這個項目能夠抽象出來什麼能夠複用的東西嗎？
• 項目中的什麼能夠不用本身作，調用現成服務嗎？

測試

• 新的系統設計是否容易獨立測試

兼容性

• 新的系統是否和已有系統衝突，怎麼融進去