這是一個工程類技術方案模板，基於我之前的一些積累，適合相對獨立的需求，實際開發中可以作為一個寬集，在這個基礎上進行增加或者刪減。
一、概要
很多時候，大家做專案的時候容易陷入為了上線而上線，尤其技術出身的同學，接到一個專案後，會陷入快速瞭解需求、做方案的圈子裡。
透過概要分析，先了解下你要做的專案、在整個業務發展過程中所處的位置及價值，可以簡單問幾個問題，相信會有所幫助：
1、專案是解決哪個業務的需求？處於什麼發展階段？
2、當前業務有哪些問題/最佳化空間/增長點，透過這個專案能否解決？
3、參與業務上下游有哪些角色？
4、專案的成本和收益如何評價，有沒有可衡量的指標體系？
5、後期業務發展的趨勢如何？未來可能的增長規模多大？
基於以上的問題，為後續落地的方案可擴充套件性及未來業務發展做預判。
1.1 術語
統一術語的目的是讓溝通在一個頻道上，避免出現雞同鴨講，在專案後期出現返工等現象。
把術語放在最開始，以確保本文件的閱讀者能夠在一篇文件中就可以瞭解所有的關鍵術語。
- 術語將貫穿需求、分析、設計、開發、測試、維護階段，在整個專案的生命週期中，參與者都將以統一的術語交流。
- 術語定義要求精確，嚴格，且勿模糊，含蓄；
- 尋找術語的方法：從需求文件中尋找那些多次出現的名詞，業務名詞，系統分析時引入的抽象概念。
- 術語範圍：產品名稱相關的名詞，業務相關的名詞，參與者相關的角色名詞，邊界、額度、時間相關的名詞，系統抽象的名詞。
- 如果在PRD文件中已經定義了某一個術語，建議在此處引用定義。
示例：
優惠券：商品促銷手段，透過發放或者領取兩種渠道，讓使用者在下單時抵扣一定的金額。
1.2 背景
背景是STAR法則中情境(situation)的體現，一般來自需求提出者，產研等部門。
背景通常包括專案內外部、團隊內外部、組織內外部、公司內外部等。
綜合不同維度上的背景，可以綜合反映專案當前的價值，幫助下一步統一專案目標。
1.3 目標
基於背景分析，明確專案的目標，專案開發的意義，挖掘使用者真實的可評測目標。
1.3.1 商業目標
商業目標一般會在PRD文件中明確，列出商業目標的目的是為了讓我們的系統分析不要偏離業務主線。
1.3.2 系統目標
系統目標是為了支援商業目標，是商業目標在系統層面的具體化。
系統目標只是達到商業目標的充分條件，當我們的系統最終達到這幾個方面，也意味著系統完全能夠支援商業目標，但商業目標能否實現，與系統目標沒有必然關係。
- 系統目標應該是具體的，可以實現的，可以達到的，相比商業目標是可落地的。
- 對於技術型比較強的系統，一些技術上要達到的指標也是重要的系統目標。比如一些中介軟體產品的技術指標，RT，SLA等。
系統目標要從當前需求出發，不侷限於當前需求。
系統分析不是簡單的對PRD當前需求的滿足，而是站在整體產品的角度來看本次需求處於產品的那個位置，該位置在產品中的目標就是一個具體的系統目標。
二、總體設計
2.1 業務主流程
“如果你不能用一個過程來描述你正在做的事情，你就不可能真正明白你在做什麼。” —— By W.愛德華茲.戴明 （PDCA迴圈的推廣者）
- 系統的業務流程與具體的一個用例的流程有哪些差異？
業務流程從系統全域性來看，用例關注的是自己內部的流程。
系統的業務流程是使用者要完成他的業務目的，在系統層面發生著什麼樣的流程、事件來支撐使用者的業務。
此處的流程節點同時是粗粒度的，它關注資料流、事件流在系統裡的流轉。
- 對於一些內部系統，如CRM、OA等，系統業務流程可能會成為設計階段的BPM流程的主要來源。
- 對於一些小的專案，可能不存在複雜的流程，它們只是簡單的請求-處理模式，此時可以不去關注系統業務流程。
- 對於那些改造型的專案，如果沒有流程的變化，可以沿用已有的用例。
- 如果發生了變化，要把2個版本都畫出來，且對差異之處進行重點說明。同時差異之處也是我們系統分析的重點。
2.2 系統整體架構
- 根據從相似系統或相似問題領域中獲取的經驗，定義備選架構和模型。
- 可以結合一些成熟的外部例項，比如電商可以參考淘寶、京東類似業務的設計。
- 通常需要產品團隊和技術同學一起迭代來確定架構和模型，可以分為業務和技術架構。
2.3 業務系統邊界
透過梳理業務系統邊界，明確系統的上下游關係。
示例：
2.4 關鍵技術及第三方框架依賴
本系統採用了哪些關鍵技術，如業務演算法、分散式session、分散式事務、分散式cache、分庫分表等。
本系統引入了哪些外部框架、jar包。
三、模組實現
3.1 整體模組設計
模組的劃分，相關描述
3.2 模組間互動介面
對介面的輸入，輸出，主要作用，使用場景做描述，輸入輸出中傳遞的值物件，也要做描述。不需要描述介面的實現細節。
3.3 狀態機設計
對於一些複雜狀態的流轉，建議透過狀態機的方式來描述。
3.4 XX模組功能實現
3.4.1 模組描述
輸入輸出，功能描述，UC圖等
示例，秒殺模組設計：
3.4.2 業務流程
幾個圖可根據情況選擇，但至少要有一個。
例如：狀態圖，流程度，順序圖
3.4.3 改造點(可選)
如果是改造型功能，列出改造
3.4.4 演算法設計(可選)
系統內用到的演算法要有技術公式和計算步驟，引數管理方案等。演算法要充分考慮效能因素，大批次操作的部分要首先保證效能。需要加密的資料要定義加解密方式。
3.4.5 核心業務邏輯類圖(可選)
核心業務邏輯的實現方法可事先定義好，把類圖畫出來
3.4.6 介面設計詳細說明
比如RPC介面，HTTP介面，可以透過單獨的文件描述
3.5 YY模組實現設計
同 XX模組設計
3.6 基礎模組設計
可以從以下幾個角度進行分析：
- 專案中那些公共元件是很多業務通用的？
- 改造了那些公共元件是替他業務也在使用的，對其他業務有什麼影響？
- 那些基礎設施在本專案中設計，但是以後也打算給其它業務使用？
- 給其它業務使用過程中是否需要擴充套件，修改？
- 本專案中是否已經做了本專案用不到的超前設計？
- 超前設計是否需要評估和測試？
3.8 關聯絡統改造
描述關聯上下游系統需要的改造。
四、資料儲存設計
描述資料庫的設計，包括新的設計和原來設計的修改。
4.1 領域模型設計
- 關注模型，設計ER圖等描述資料庫設計
示例，許可權模型的ER圖：
4.2 資料庫設計
4.2.1 表結構設計
- 表中欄位長度要留有餘量，每個欄位都要有詳細說明
- 如果記錄可能刪除，建議用DELETED表示是否刪除（0正常，-1刪除）]
- 預估變化比較多的表，可以增加extend活著feature欄位，用於將來可能增加的欄位，以鍵值對形式追加
4.2.2 分庫分表設計
- 影響分表選擇的因素是表的業務是否支援水平拆分、表的大小、表的訪問量（QPS+TPS）。
- 拆分的前提是表的業務有一個好的水平拆分維度。如買家id、商家id、訂單id，都可以作為拆分的維度。、業務SQL，必須避免跨分表。
- 表大小上一定規模後，無論是根據pk查詢還是根據二級索引查詢，sql的rt都會隨著表的大小增長而增長，最終超出應用對資料庫響應時間的需求。所以，表大了要分表。
- 表的訪問量上一定規模後，對於根據二級索引查詢，sql的rt會隨著page讀寫衝突機率的增加而增長，最終超出應用對資料庫響應時間的需求。所以，表的訪問量高了也要分表。
4.2.3 資料字典設計
- 資料字典中要定義狀態值描述
4.2.4 索引設計
- 列出使用的主鍵索引，唯一索引，普通索引。
- 常用的組合查詢條件等
4.2.5 最佳化設計
注：資料冗餘，最佳化查詢方案等
- 表之間的關係要簡單，涉及到多表的複雜查詢和跨資料庫的操作要合理使用冗餘欄位。
- 資料刪除一般要採用邏輯刪除，邏輯刪除的資料要有清理機制。
- 合理利用事務，誤操作後資料如何恢復。
- 根據資料流量，執行頻率，制定分頁方案。
- 要考慮資料庫的設計方案對儲存成本有多少影響。
4.3 快取方案設計
- 快取選型，本地快取設計，分散式快取設計
- 進一步需要考慮快取失效等常見問題
4.4 ES索引設計
列出可能需要的索引層設計。
五、資料安全和風控
5.1 業務和資料安全
業務安全可以從如下幾個方面考慮：
- 外部系統提交的資料是完整的，能夠滿足我方進行資料核對的需求
- 我方返回的資料是完整的，能夠滿足外部系統進行資料核對的需求
- 業務資料的機密性，關鍵業務資料、敏感業務資料
- 傳輸過程中涉及到隱私和機密性，需要找出來，採取對應的措施予以解決
- 系統支援那些型別的外部訪問者，對訪問者進行標示，訪問者標示和業務資料的關係限制
- 併發情況下，資料的安全性，主要體現在髒資料，錯誤資料方面
- 當存在與外部資料關聯的情況下，如果關聯失敗後，資料不完整的處理方案
5.2 資損風險分析
只要涉及資金（如廣告消耗）和電商履約（如商品出庫）的專案,都存在資損風險。
5.2.1 風險列表描述
- 新增資損評估checklist內容。
- 本專案所有的資損風險點，在此處都要有分析描述。
5.2.2 資損防控方案分析
針對某些資損風險點，需要透過一個完整的方案才能從根源上解決資損風險，具體的方案分析在這裡展開。
比如，在做電商退貨退款的業務設計，我們要從幾個角度進行防資損：
- 保證退款業務操作的唯一性，針對所有請求都遵循冪等性原則；
- 保證冪等檢查的正確性，如果透過資料庫進行冪等控制，要考慮業務重試的風險；
- 保證退款金額的合理性，退款金額不超出原有的支付金額，在系統模型的設計上要有所體現；
- 保證併發情況下，不會出現超額退款；
六、效能和可測性
6.1 容量規劃
從系統目標和業務的角度，進行合理的容量規劃。
6.2 效能分析
從業務的角度分析對效能的需求：
• 對事務的響應時間（平均、最長）
• 吞吐量（例如每秒處理的事務數）
• 容量（例如業務所能容納的客戶或事務數）
在效能分析的時候，通常關注業務鏈路的起點、連線點、受限制的資源點。
6.2.1 併發訪問控制
至少可以從以下方面分析：
- 有沒有資源需要併發訪問控制？
- 有沒有資源在併發控制出錯的情況下會造成損失？
- 併發訪問控制會不會造成效能瓶頸？
6.2.2 介面效能延時要求
- 有沒有具體的指標或要求？
- 有沒有可能影響現有系統?
避免使用統一的指標要求所有業務，可能各個系統use case，或各個業務有不同的效能要求，應該要分別描述。
6.3 可測性分析
可以從以下方面分析：
- 系統依賴的外部環境是否可以測試，是否需要開發專門的mock系統
- 系統依賴的時間因素是否可以測試，是否需要開發專門的配合工具進行測試
- 系統依賴的時間，環境，許可權等因素是否可以預釋出確認，是否需要特別的準備才可以預釋出確認。
- 系統依賴的特殊因素如果不能很好的測試或預釋出確認，是否需要試執行策略？
七、穩定性設計
7.1 系統降級方案
考慮極端場景下，系統的降級方案。
7.2 系統容錯分析
系統的容錯能力可以從以下方面進行分析：
一、系統所依賴的外部系統發生一些錯誤的時候，系統有沒有相應的容錯機制
二、系統所依賴的硬體網路等基礎設施發生故障，系統有沒有相應的容錯機制
由於所選擇的通訊，儲存等方面的不可確定的因素，以及在某一個臨界點處導致的質變，需要我們在此處指出可能存在的風險以及解決方案。
- 通訊層面常出故障：例如頻寬太小
- 檔案系統：檔案系統損壞、檔案系統容量、檔案系統每個目錄所能容納的目錄、檔案數量的限制
- 檔案系統同時開啟的控制程式碼數的限制，間接影響併發行、檔案自身的損壞
7.3 系統和業務監控
可以從以下方面分析：
- 系統釋出和執行期間是否需要系統日誌做監控
- 系統釋出和執行期間是否要對原有業務做監控，以便知道影響
- 有沒有制定新的一些重要的監控指標
- 系統是否在特定情況下需要一些報警
- 系統有沒有考慮以後方便的擴充監控
- 監控發現嚴重問題是否有方法來得及挽回損失
7.4 系統日誌
可以從以下方面分析：
- 日誌的寫入量有沒有明顯變化，非同步或者同步，會不會影響業務
- 是否有新的需要長期歸檔的日誌，請遵守命名規範
- 那些業務需要從日誌中進行分析，以方便進行監控或排錯
- 作為外部互動憑據的日誌是否有歸檔，並和其它日誌分開
八、資料影響分析
8.1 對已有業務資料分析的影響
可以從以下方面分析：
- 本專案所作的改造有沒有影響現有的資料分析進行
- 本專案所作的改造有沒有影響現有的業務資料分析結果
- 如果不明確影響，應該主動找資料分析團隊溝通
8.2 釋出期間影響分析
可以從以下方面分析：
- 是否有相容方案，可以做到業務無感知
- 系統釋出期間服務是否正常可用
- 系統釋出期間對使用者有沒有影響
- 系統釋出期間新老系統共存產生的資料有沒有影響
- 各個系統釋出順序有沒有要求
- 系統釋出期間的相容性是否建議專門測試
8.3 資料歸檔方案
可以從以下方面分析：
- 新增的表是否需要回流到HIVE表進行儲存
- 如果表的數量持續增長，是否需要進行資料歸檔，對歷時資料進行定期清理
九、工作量評估
9.1 工作量評估
拆解到人天，可以劃分具體里程碑。
十、釋出計劃
10.1 上線計劃
根據具體的業務情況，選擇是否需要灰度上線、AB方案等。