Design Review 是我們開發過程中至關重要的一環，一個好的Design review不但能讓我們的技術方案考慮的更加周全，更多時候還可以大大節省我們的工作量，並減少未來的線上Bug以及不必要的反覆修改。
Design Review的過程中需要考慮的問題涉及方方面面，下面是我們在這個環節經常問的一些問題，雖然我們不是每個項目都會涉及到下面所有的這些點，而且我們也不應該被這些問題所侷限，但作爲一個參考，這些問題依然能給我們提供一個好的思考框架。
---------------------------------------------------- --------- --------- --------- --------- --------- --------- --------- --------- ---------
可用性
- 外部依賴有哪些？如果這些外部依賴崩潰了我們有什麼處理措施？
- 我們SLA是什麼？主要是指可用性目標幾個9? 50/90/99分位數的響應時間是多少? QPS是多少?
- 我們的超時、重試、過載保護、服務降級機制是什麼？如何避免雪崩
- 我們的調用方有哪些？分別有什麼服務配額？是否需要對關鍵的服務調用方單獨部署？
運維
- 我們都有配置了哪些監控？如果出現問題，我們需要查看哪些信息？這些信息是否都有記錄？
- 報警的處理流程是什麼？
- 系統上線流程和步驟是什麼，出了問題後是否可以回滾，以及怎麼回滾？
安全
- XSS，CSRF，SQL注入這些是否需要處理？
- 3防怎麼搞：防抓，防DDOS，防惡意訪問
- 是否有請安全團隊review
- 是否有風控的需求？
- 信息存儲時是否設計到密碼，信用卡，身份證等敏感信息，這些信息是怎麼存儲和訪問的？
- 系統是否符合公司的安全規範(SSO, 接口認證)？關鍵業務操作是否可審計(可回溯誰在什麼時間幹了什麼操作)
擴展性
- 分層，分模塊怎麼拆分比較合理？拆分出來的模塊可以搞成服務單獨部署嗎？
- 應用層可以水平擴展嗎？有用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)？爲什麼用它們？
- DB是否可以用、以及用哪種no sql(hbase, tair)來優化？
- 業界或者其他團隊是否有處理過類似問題？他們是怎麼處理的？是否可以copy或者借鑑？
服務調用和服務治理
- 請求同步處理還是異步隊列處理比較好？
- 服務接口的URI設計合理嗎？可以向下兼容嗎？
- 服務間的調用協議是什麼？有公司標準的調用協議可以用嗎？
- 客戶端和服務端的調用協議是什麼？有公司標準的調用協議可以用嗎？
- 有什麼服務治理相關的要考慮的嗎？
- 能否接入otco或者sg做服務治理？
業務監控
- 正常的業務邏輯外，可能會有哪些奇葩或者惡意的操作？我們應該怎麼處理？
- 除了系統上的監控外，需要什麼業務維度的監控嗎？
- log是怎麼記的？如果要debug能有什麼開關迅速打開嗎？log怎麼rotate？log會影響性能嗎？
複用
- 項目中有用什麼新技術嗎？爲什麼要用新技術？未來其他人接手容易嗎？
- 項目中有什麼複雜計算的地方嗎？這些計算可以用什麼算法優化嗎？
- 這個項目可以抽象出來什麼可以複用的東西嗎？
- 項目中的什麼可以不用自己做，調用現成服務嗎？
測試
- 新的系統設計是否容易獨立測試
兼容性
- 新的系統是否和已有系統衝突，怎麼融進去
ps：轉載自之前的總監總結的design review