大家好，我是老三，轉眼間，團隊的技術專家B哥，已經離職一年了，我還時不時會想起他，因為他留下的j技術設計模版，我覺得真的很好用，基本上涵蓋了設計需要考慮的方方面面。接下來，以一個CRM項目的用戶觸達模塊為例，給大家分享一下。

一、CRM_技術設計文檔_消息觸達模塊

老三說：第一部分主要說明項目或者模塊的概況，這一部分雖然不太重要，但是是必須的。

二、修訂記錄

老三說：技術設計不是一成不變的，經常會隨著業務的變化，或者根據遇到的一些問題，進行完善和優化，但是每一個版本，都應該留下記錄和備份。

三、需求/背景

產品文檔：xxxx

為了實現用戶的精細化運營，通過多種途徑，向用戶發送消息通知……

老三說：這一部分就是結合產品文檔，把需求/背景簡單提煉一下，必須，但不是重點。

四、設計目標

老三說：設計目標一般分為兩部分：

實現功能：這一部分就是就是分析需求，把產品文檔里的東西，拆解成一個個的功能，也就是CRUD。

設計指標：CRUD也有區別，一把梭，隨便寫也能實現功能，但是我們CRUD也得有點追求，而且面向C端用戶的系統，也基本上會有一些性能、可用性之類的要求，比如接口響應平均多少多少毫秒以下、單機QPS1000、系統幾個9可用……

4.1.實現功能

1. 多種渠道給用戶推送消息，主要包含站內和站外兩大部分：

• 站內：

站內信

彈屏

• 站外：

• 郵件

• 短信

• push

• 微信

• ……

2. 觸達任務管理

• 支持定時/延時消息發送
• 支持觸發型消息發送
• 支持用戶分群發送

……

老三說：功能點比較多的話，這一部分還可以用思維導圖的形式來整理。

思維導圖

老三說：這一部分評審的時候一定要拉上產品經理或者相關的業務方，確定功能點沒有錯漏。

4.2.設計指標

1. 性能要求

• 百萬級消息分鐘級發送完成
• xx接口，性能指標：單機1000并發，95%響應<=200ms

……

老三說：一般C端的服務都是有比較嚴格的性能要求的，畢竟如果系統響應慢的話，用戶的流失率就會變高。當然，用戶觸達，其實主要在于推，用戶主動查會少一些，消息的推送通常也會要求速度，比如，有個網紅，九點鐘要在app上直播，直播開始的時候，要做一個推送，那就要求盡可能快地把消息推送給每個用戶，不能說等到十二點直播完了，有的用戶才收到消息。

2. 可用性

• 觸達模塊99.9%可用
• 消息推送成功率80%以上

……

老三說：C端系統的可用性比較重要，畢竟掛一會，影響的用戶可能都是以萬計，所以，設計的時候，也要考慮可用性，分析系統的瓶頸在哪里，流量突然上來，哪里可能頂不住，是要擴容，還是要限流、熔斷降級……

3. 擴展性

• 采用策略模式+配置，新增消息渠道，只需少量代碼+代碼即可實現
• 引入規則引擎，同一消息類型的不同渠道，可以通過規則調整，無需發版

……

老三說：這一部分也是設計中應當考慮的，不能一味求快，否則很容易堆屎山。

4. 兼容性

• 接口xxx向前兼容app 1.9.0版本，低版本需強制更新

……

老三說：C端系統的開發，有時候比較麻的是低版本app的兼容，盡可能早期設計的時候，就考慮可能的擴展，如果實在沒法兼容，那就只能app強制更新，當然這種用戶體驗就非常不好了。

5. 可觀測性

• 接入Prometheus和Grafana，對服務和業務進行監控

• 服務監控：通過控制面板觀察服務的內存、CPU、JVM、接口QPS、接口RT……
• 業務監控：通過埋點上報，收集用戶觸達數據，通過面板可以分設備、渠道查看用戶觸達成功率……

老三說：這一部分也很重要，我們一般上班的第一件事，就是看監控面板，分析有沒有什么異常的地方。服務的可觀測性，一般公司都是用一些開源的或者付費的監控平臺，大廠一般都會自研監控平臺。服務的監控很多是通過插樁來實現，業務的監控一般都需要打埋點。

6. 告警

• 通過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：用戶觸達任務表

老三說：數據模型設計非常重要，可以說是系統設計的根基，如果沒有設計好，開發和維護起來真的很痛苦，每個公司應該都有一定的數據庫設計規范，基本就是結合業務和規范來設計了。

具體用什么工具設計呢？業務比較簡單的C端系統，其實直接拿表格也行，之前也試過PdMan，還行吧。

6.4.接口設計

老三說：這一部分也是重量級，但凡涉及到客戶端，或者其它服務的，這一部分都少不了，一般可以通過YApai之類的接口工具，但是建議大家還是在文檔里做個重復工作，把入參出參之類的描述一下，有些地方標標重點，因為有些人真的不怎么會看文檔。

接口設計的時候一定要和相關的同學對齊，不要怕花時間，后期改接口，是一件很痛苦的事情。

6.5.異常處理

• 系統中的不確定異常，進行統一處理，響應“Network Error”
• 埋點異步發送，不影響主要功能
• ……

老三說：異常處理也是需要考慮的地方，哪些異常可以吞掉降級，哪些沒法處理，怎么給客戶端展示，怎么打日志，都需要考慮。

七、風險評估

老三說：其實每一次上線都伴隨著風險，從設計，一直到上線之前，都要對存在的風險進行評估，上線了要重點觀察風險點，也要提前設計好回滾或者處理方案，一旦發現不對勁，及時回滾和處理。

7.1.已知風險

• 對數據相關服務壓力較大，用戶分群、用戶畫像等數據服務崩潰風險
• MQ存在堆積風險，導致用戶收到消息延遲
• QPS較高，數據庫CPU飆升風險
• ……

7.2.可能風險

• 場景類消息延遲，可能會影響交易相關流程，拉低轉化率和成交率

……

八、測試建議

老三說：需求評審階段、設計評審階段，最好都拉上測試同學，測試同學要對整體的功能，還有性能，都有比較清楚的了解。但是啊，如果只看功能的話，可能就是表面的點點點，具體實現邏輯，還是開發比較清楚，所以說給測試同學提一些測試建議，給測試的測試用例提供參考。

同時，我個人覺得，從測試的角度進行思考，也能有效減少寫代碼的bug。

8.1.功能測試

老三說：這一部分基本就是結合設計目標的實現功能，列一下測試步驟和預期結果

8.2.性能測試

• xxx接口壓測，預估單機QPS1000

這一部分基本就是壓測了，很多時候，系統的壓測沒那么簡單，尤其是鏈路長的時候，壓一次都得興師動眾。

九、上線準備

• 運維搭建環境
• 數據初始化
• 添加配置
• 消息隊列創建
• 依賴服務上線
• 服務上線

老三說：這一部分算是上線的備忘吧，有些wiki類的工具，支持在文檔里建任務，把上線前需要做的事情列出來，有不知道你經歷過“測試環境猛如虎，上線一看原地杵”沒？可能就是上線準備沒做好，缺了什么，少了什么。

十、評審及意見

老三說：設計文檔不是寫完，啪，丟出去就完事了，還要上設計評審會，評審的時候，通常相關同學會提出一些評審意見，這些都應該記錄下來，解決完了之后，再次評審，直到評審通過，然后就可以開始CRUD了。

好了，看完這個模板，想必你對技術設計也有一定的認識了，老三實際上沒怎么接觸過用戶運營相關的東西，所以內容大家隨便看看，主要看模板。

當然模板是相對固定的，但是設計是靈活的，做技術設計的時候，也不用拘泥于固定的形式，根據具體的需求，考慮到需要考慮的點，能做到設計指導開發就夠了。

那么，假如你已經能做好技術設計……

但是——

老板：三某，這個需求，三天能不能搞定？

老三：可能不太……

老板：這個需求很急，而且我不能不急，你懂我的意思吧？

老三：沒問題，三天夠了！

而且——

老板：呦，三某的文檔寫的很清晰，代碼也很優雅，今年公司績效不好，找個實習生把他替了吧。

……

繃不住

參考：

[1].用戶運營：觸達系統應該如何搭建:https://www.woshipm.com/user-research/4239618.html)

[2].一個實時精準觸達系統的自我修養:https://juejin.cn/post/6844904009770221581