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

一、CRM_技術設計文件_訊息觸達模組

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

二、修訂記錄

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

三、需求/背景

產品文件：xxxx

為了實現使用者的精細化運營，透過多種途徑，向使用者傳送訊息通知……

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

四、設計目標

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

• 實現功能：這一部分就是就是分析需求，把產品文件裡的東西，拆解成一個個的功能，也就是CRUD。
• 設計指標：CRUD也有區別，一把梭，隨便寫也能實現功能，但是我們CRUD也得有點追求，而且面向C端使用者的系統，也基本上會有一些效能、可用性之類的要求，比如介面響應平均多少多少毫秒以下、單機QPS1000、系統幾個9可用……

4.1.實現功能

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

• 站內：
• 站內信
• 彈屏
• 站外：
• 郵件
• 簡訊
• push
• 微信
• ……

1. 觸達任務管理

• 支援定時/延時訊息傳送
• 支援觸發型訊息傳送
• 支援使用者分群傳送

……

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

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

4.2.設計指標

1. 效能要求

• 百萬級訊息分鐘級傳送完成
• xx介面，效能指標：單機1000併發，95%響應<=200ms

……

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

1. 可用性

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

……

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

1. 擴充套件性

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

……

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

1. 相容性

• 介面xxx向前相容app 1.9.0版本，低版本需強制更新

……

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

1. 可觀測性

• 接入Prometheus和Grafana，對服務和業務進行監控
• 服務監控：透過控制皮膚觀察服務的記憶體、CPU、JVM、介面QPS、介面RT……
• 業務監控：透過埋點上報，收集使用者觸達資料，透過皮膚可以分裝置、渠道檢視使用者觸達成功率……

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

1. 告警

• 透過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流程

老三說：使用者觸達，業務流程基本比較簡單，對於一些交易類的，比如支付，或者B端的系統，比如ERP，在開始開發之前，流程一定要梳理清楚，一般透過流程圖、時序圖來描述業務流程。給大家看一下我之前對接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了。

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

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

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

但是——

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

老三：可能不太……

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

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

而且——

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

……