1、確認需求：
- 用自己的話再給對方複述一遍
2、分析需求：
- 表面需求
- 內在需求
- 擴展需求
- 是否合理
3、分析資源：
- 人+資源+時間+依賴資源
4、邊界：
- 功能性需求（數據收集、加工、存儲、展示）
- 非功能性需求（易用性、可用性、性能、完整性、強一致性等）
5、技術選型-技術廣度：
- 已有輪子
- 自己寫輪子
6、概要設計：
- 架構圖等
7、詳細設計：
- 領域模型、UML圖、數據庫表結構等
8、接口基本設計：
- 接口的命名、請求參數、支持的協議。
- TPS、併發數、響應時長。
- 數據存儲。DB選型、緩存選型。
- 是否需要依賴於第三方。
- 接口是否拆分。
- 接口是否需要冪等。
- 防刷。
- 接口限流、降級。
- 負載均衡器支持。
- 如何部署。
- 是否需要服務治理。
- 是否存在單點。
- 接口是否資源包、預加載還是內置。
- 是否需要本地緩存。
- 是否需要分佈式緩存、緩存穿透怎麼辦。
- 是否需要白名單。
8、系統的可用性、可靠性、可擴展性、可維護性方面延伸：
- 接口設計原則：
- 必須符合Restful，統一返回格式，約定業務層錯誤編碼，每個編碼可以攜帶可選的錯誤信息。
- 可擴展。
- 必須有文檔。
- 設計接口的時候就很常發現很多交互文檔走不通，產品沒有考慮到位，交互文檔缺失，開發要主動推動，完善。
- 第三方服務接口數據能緩存就緩存。
- 第三方服務需要做降級。
- 客戶端能處理的邏輯就不要給服務端處理，減少服務端壓力。
- 資源預加載。
- 接口高性能：
- A：數據存儲方面：我們會想數據庫有沒有分庫、分表、有沒有做主從，有沒有讀寫分離、字段是否有加索引、是否存在慢sql，數據庫引擎是否選用合適、是不是用了事務；其次我們會想到是不是引用了分佈式緩存、緩存key大小是否合適，失效時間是否設置合理，會不會大量緩存穿透、有沒有引入本地緩存。
- B：業務方面：是否有大量的計算、能否異步處理。是否需要引入線程池或者MQ來異步處理任務。有沒有必要將接口進行垂直拆分和水平拆分、將接口粒度變小。
- C：其他方面：nginx層面做緩存、加機器、用ssd，資源放cdn，多機房部署、資源文件預加載。
- 接口高可用：
- A：消除單點。
- B：能做集羣的全部做集羣。譬如Redis集羣、MySQL集羣、Kafka集羣、MongoDB副本集。
- C：能做讀寫分離的都做讀寫分離。
- D：異地多機房部署，接入GSLB。
- E：必須有限流、降級機制。
- F：監控。