團隊技術專家回老家了，留下的技術設計模版賊好用！
大家好，我是老三，轉眼間，團隊的技術專家B哥，已經離職一年了，我還時不時會想起他，因為他留下的j技術設計模版，我覺得真的很好用，基本上涵蓋了設計需要考慮的方方面面。接下來，以一個CRM項目的用戶觸達模塊為例，給大家分享一下。
一、CRM_技術設計文檔_消息觸達模塊
項目名稱 | CRM系統 |
項目負責人 | 三分惡 |
模塊名稱 | 用戶觸達模塊 |
模塊負責人 | 三分惡 |
老三說：第一部分主要說明項目或者模塊的概況，這一部分雖然不太重要，但是是必須的。
二、修訂記錄
版本 | 修訂人 | 修訂內容 | 修訂日期 |
V1.0 | 三分惡 | 創建 | 2022-12-23 |
老三說：技術設計不是一成不變的，經常會隨著業務的變化，或者根據遇到的一些問題，進行完善和優化，但是每一個版本，都應該留下記錄和備份。
三、需求/背景
產品文檔：xxxx
為了實現用戶的精細化運營，通過多種途徑，向用戶發送消息通知……
老三說：這一部分就是結合產品文檔，把需求/背景簡單提煉一下，必須，但不是重點。
四、設計目標
老三說：設計目標一般分為兩部分：
實現功能：這一部分就是就是分析需求，把產品文檔里的東西，拆解成一個個的功能，也就是CRUD。
設計指標：CRUD也有區別，一把梭，隨便寫也能實現功能，但是我們CRUD也得有點追求，而且面向C端用戶的系統，也基本上會有一些性能、可用性之類的要求，比如接口響應平均多少多少毫秒以下、單機QPS1000、系統幾個9可用……
4.1.實現功能
- 多種渠道給用戶推送消息，主要包含站內和站外兩大部分：
- 站內：
站內信
彈屏
- 站外：
郵件
短信
push
微信
……
- 觸達任務管理
- 支持定時/延時消息發送
- 支持觸發型消息發送
- 支持用戶分群發送
……
老三說：功能點比較多的話，這一部分還可以用思維導圖的形式來整理。
思維導圖
老三說：這一部分評審的時候一定要拉上產品經理或者相關的業務方，確定功能點沒有錯漏。
4.2.設計指標
- 性能要求
- 百萬級消息分鐘級發送完成
- xx接口，性能指標：單機1000并發，95%響應<=200ms
……
老三說：一般C端的服務都是有比較嚴格的性能要求的，畢竟如果系統響應慢的話，用戶的流失率就會變高。當然，用戶觸達，其實主要在于推，用戶主動查會少一些，消息的推送通常也會要求速度，比如，有個網紅，九點鐘要在app上直播，直播開始的時候，要做一個推送，那就要求盡可能快地把消息推送給每個用戶，不能說等到十二點直播完了，有的用戶才收到消息。
- 可用性
- 觸達模塊99.9%可用
- 消息推送成功率80%以上
……
老三說：C端系統的可用性比較重要，畢竟掛一會，影響的用戶可能都是以萬計，所以，設計的時候，也要考慮可用性，分析系統的瓶頸在哪里，流量突然上來，哪里可能頂不住，是要擴容，還是要限流、熔斷降級……
- 擴展性
- 采用策略模式+配置，新增消息渠道，只需少量代碼+代碼即可實現
- 引入規則引擎，同一消息類型的不同渠道，可以通過規則調整，無需發版
……
老三說：這一部分也是設計中應當考慮的，不能一味求快，否則很容易堆屎山。
- 兼容性
- 接口xxx向前兼容app 1.9.0版本，低版本需強制更新
……
老三說：C端系統的開發，有時候比較麻的是低版本app的兼容，盡可能早期設計的時候，就考慮可能的擴展，如果實在沒法兼容，那就只能app強制更新，當然這種用戶體驗就非常不好了。
- 可觀測性
- 接入Prometheus和Grafana，對服務和業務進行監控
- 服務監控：通過控制面板觀察服務的內存、CPU、JVM、接口QPS、接口RT……
- 業務監控：通過埋點上報，收集用戶觸達數據，通過面板可以分設備、渠道查看用戶觸達成功率……
老三說：這一部分也很重要，我們一般上班的第一件事，就是看監控面板，分析有沒有什么異常的地方。服務的可觀測性，一般公司都是用一些開源的或者付費的監控平臺，大廠一般都會自研監控平臺。服務的監控很多是通過插樁來實現，業務的監控一般都需要打埋點。
- 告警
- 通過PrometheusAlert實現服務的告警，告警信息分級別，進行飛書通知、電話通知，告警類型分為服務告警和業務告警
- 服務告警：內存、CPU占用過高，接口QPS過多，接口RT過長，觸發告警
- 業務告警：用戶觸達成功率過低告警
老三說：告警通常也是和監控在一起的，畢竟開發人員也不可能二十四小時盯著告警，一般開源的、付費的、自建的監控系統，都支持配置告警規則，并通過不同的方式，郵件、短信、電話之類的渠道進行通知。
五、概要設計
老三說：概要設計，就是做個大概的系統整體設計。
5.1.設計思路
- 數百萬消息段時間發送完成，流量較大，對數據存儲性能要求較高，需要選用高性能DB，對存儲壓力也比較大，同時需要一定削峰處理
- 定時/延時消息發送采用消息隊列實現，對MQ的消費要求較高，并發度要高，批量消費
- ……
老三說：這一部分主要是梳理一下整體的開發設計思路，把一些零散的想法梳理成點或者面，前期大家的討論可以整理在這里。
5.2.技術選型
- 存儲：TiDB
- 緩存：Redis
- 消息隊列：業務RocketMQ，埋點Kafka
- 注冊中心：Nacos
- 配置中心：Nacos
- RPC：Dubbo
- 網關：Gateway
- Push通道：自建
……
老三說：這一部分就是大概定一下技術選型，其實要是整個項目做好了選型，這一部分也可以不做，一般需要高級技術人員或者架構師，來整體地進行把握，當然，很多時候選型也沒好選的，基本就是主流的那些，而且一般一個團隊，都是統一的技術選型，方便維護。
5.3.業務架構
業務架構
老三說：這一部分就是大概對功能分分層，分分塊，把大概的功能切一切。
5.4.技術架構
老三說：技術選型+業務架構，其實一個大概的技術架構就出來了。
技術架構
老三說：技術架構圖類型，其實也沒有特別固定的形式，主要是圖能達意，我這個圖是通過draw.io畫的，還有一些其它的還用的工具，比如大家應該都聽過“PPT架構師”，用PPT畫也是可以的。當然這個圖是我隨手畫的。
5.5.系統環境
- JDK版本：11
- 部署環境：k8s+Containerd，單pod8核CPU+4G內存，服務集群32個pod
- 數據庫：
- 業務數據：TiDB 64核CPU+128G內存
- 離線數據：Hbase……
- ……
老三說：如果是項目初建，一般還需要對系統的環境進行評估，根據技術選型、數據容量、系統QPS等等，來選擇系統的環境，這一部分一般評審的時候會拉上運維同學，提前確定好系統環境，和運維同學對齊需求和排期。
六、詳細設計
老三說：詳細設計，就是具體指導開發的設計部分了，包括流程啊、數據模型啊、具體用到的算法、和客戶端的接口，等等，這一部分很重要，如果沒做好，沒對齊，那么搞不好就要返工，耽誤進度。
6.1.流程設計
- push流程
push流程
老三說：用戶觸達，業務流程基本比較簡單，對于一些交易類的，比如支付，或者B端的系統，比如ERP，在開始開發之前，流程一定要梳理清楚，一般通過流程圖、時序圖來描述業務流程。給大家看一下我之前對接alipay畫的簡單的時序圖：
Alipay接入時序圖
6.2.算法設計
- 渠道分流：同一消息類型，多種渠道，支持按比例分流，采用加權隨機算法實現
- ……
老三說：算法設置不一定數據結構相關的算法，代碼里的一些涉及到一些需要進行邏輯計算的，都可以稱之為算法，這一部分也可以先梳理一下。
6.3.數據模型設計
- crm_user_toutch_tash：用戶觸達任務表
字段 | 描述 | 數據類型 |
id | 主鍵 | bigint |
task_no | 任務編號 | bigint |
comment | 描述 | varchar |
…… |
老三說：數據模型設計非常重要，可以說是系統設計的根基，如果沒有設計好，開發和維護起來真的很痛苦，每個公司應該都有一定的數據庫設計規范，基本就是結合業務和規范來設計了。
具體用什么工具設計呢？業務比較簡單的C端系統，其實直接拿表格也行，之前也試過PdMan，還行吧。
6.4.接口設計
接口名稱 | 添加支付任務 |
接口文檔地址 | |
入參 | |
入參描述 | comment：任務描述 |
出參 | |
出參描 |
老三說：這一部分也是重量級，但凡涉及到客戶端，或者其它服務的，這一部分都少不了，一般可以通過YApai之類的接口工具，但是建議大家還是在文檔里做個重復工作，把入參出參之類的描述一下，有些地方標標重點，因為有些人真的不怎么會看文檔。
接口設計的時候一定要和相關的同學對齊，不要怕花時間，后期改接口，是一件很痛苦的事情。
6.5.異常處理
- 系統中的不確定異常，進行統一處理，響應“Network Error”
- 埋點異步發送，不影響主要功能
- ……
老三說：異常處理也是需要考慮的地方，哪些異?？梢酝痰艚导墸男]法處理，怎么給客戶端展示，怎么打日志，都需要考慮。
七、風險評估
老三說：其實每一次上線都伴隨著風險，從設計，一直到上線之前，都要對存在的風險進行評估，上線了要重點觀察風險點，也要提前設計好回滾或者處理方案，一旦發現不對勁，及時回滾和處理。
7.1.已知風險
- 對數據相關服務壓力較大，用戶分群、用戶畫像等數據服務崩潰風險
- MQ存在堆積風險，導致用戶收到消息延遲
- QPS較高，數據庫CPU飆升風險
- ……
7.2.可能風險
- 場景類消息延遲，可能會影響交易相關流程，拉低轉化率和成交率
……
八、測試建議
老三說：需求評審階段、設計評審階段，最好都拉上測試同學，測試同學要對整體的功能，還有性能，都有比較清楚的了解。但是啊，如果只看功能的話，可能就是表面的點點點，具體實現邏輯，還是開發比較清楚，所以說給測試同學提一些測試建議，給測試的測試用例提供參考。
同時，我個人覺得，從測試的角度進行思考，也能有效減少寫代碼的bug。
8.1.功能測試
功能 | 測試步驟 | 預期結果 |
定時消息發送 | 創建定時消息 | 消息定時發送 |
…… |
老三說：這一部分基本就是結合設計目標的實現功能，列一下測試步驟和預期結果
8.2.性能測試
- xxx接口壓測，預估單機QPS1000
這一部分基本就是壓測了，很多時候，系統的壓測沒那么簡單，尤其是鏈路長的時候，壓一次都得興師動眾。
九、上線準備
- 運維搭建環境
- 數據初始化
- 添加配置
- 消息隊列創建
- 依賴服務上線
- 服務上線
老三說：這一部分算是上線的備忘吧，有些wiki類的工具，支持在文檔里建任務，把上線前需要做的事情列出來，有不知道你經歷過“測試環境猛如虎，上線一看原地杵”沒？可能就是上線準備沒做好，缺了什么，少了什么。
十、評審及意見
評審意見 | 提出人 | 提出日期 | 解決意見 | 解決人 | 解決日期 |
xxx接口需要考慮一下兼容性，建議xx字段，從object改為list | 老六 | 2023年1月1日 | 修改字段類型 | 老三 | 2023年1月1日 |
…… |
老三說：設計文檔不是寫完，啪，丟出去就完事了，還要上設計評審會，評審的時候，通常相關同學會提出一些評審意見，這些都應該記錄下來，解決完了之后，再次評審，直到評審通過，然后就可以開始CRUD了。
好了，看完這個模板，想必你對技術設計也有一定的認識了，老三實際上沒怎么接觸過用戶運營相關的東西，所以內容大家隨便看看，主要看模板。
當然模板是相對固定的，但是設計是靈活的，做技術設計的時候，也不用拘泥于固定的形式，根據具體的需求，考慮到需要考慮的點，能做到設計指導開發就夠了。
那么，假如你已經能做好技術設計……
但是——
老板：三某，這個需求，三天能不能搞定？
老三：可能不太……
老板：這個需求很急，而且我不能不急，你懂我的意思吧？
老三：沒問題，三天夠了！
而且——
老板：呦，三某的文檔寫的很清晰，代碼也很優雅，今年公司績效不好，找個實習生把他替了吧。
……
繃不住
參考：
[1].用戶運營：觸達系統應該如何搭建:https://www.woshipm.com/user-research/4239618.html)
[2].一個實時精準觸達系統的自我修養:https://juejin.cn/post/6844904009770221581
