大家好，我是老三，轉(zhuǎn)眼間，團(tuán)隊(duì)的技術(shù)專家B哥，已經(jīng)離職一年了，我還時(shí)不時(shí)會(huì)想起他，因?yàn)樗粝碌膉技術(shù)設(shè)計(jì)模版，我覺得真的很好用，基本上涵蓋了設(shè)計(jì)需要考慮的方方面面。接下來，以一個(gè)CRM項(xiàng)目的用戶觸達(dá)模塊為例，給大家分享一下。

一、CRM_技術(shù)設(shè)計(jì)文檔_消息觸達(dá)模塊

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

二、修訂記錄

老三說：技術(shù)設(shè)計(jì)不是一成不變的，經(jīng)常會(huì)隨著業(yè)務(wù)的變化，或者根據(jù)遇到的一些問題，進(jìn)行完善和優(yōu)化，但是每一個(gè)版本，都應(yīng)該留下記錄和備份。

三、需求/背景

產(chǎn)品文檔：xxxx

為了實(shí)現(xiàn)用戶的精細(xì)化運(yùn)營，通過多種途徑，向用戶發(fā)送消息通知……

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

四、設(shè)計(jì)目標(biāo)

老三說：設(shè)計(jì)目標(biāo)一般分為兩部分：

實(shí)現(xiàn)功能：這一部分就是就是分析需求，把產(chǎn)品文檔里的東西，拆解成一個(gè)個(gè)的功能，也就是CRUD。

設(shè)計(jì)指標(biāo)：CRUD也有區(qū)別，一把梭，隨便寫也能實(shí)現(xiàn)功能，但是我們CRUD也得有點(diǎn)追求，而且面向C端用戶的系統(tǒng)，也基本上會(huì)有一些性能、可用性之類的要求，比如接口響應(yīng)平均多少多少毫秒以下、單機(jī)QPS1000、系統(tǒng)幾個(gè)9可用……

4.1.實(shí)現(xiàn)功能

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

• 站內(nèi)：

站內(nèi)信

彈屏

• 站外：

• 郵件

• 短信

• push

• 微信

• ……

2. 觸達(dá)任務(wù)管理

• 支持定時(shí)/延時(shí)消息發(fā)送
• 支持觸發(fā)型消息發(fā)送
• 支持用戶分群發(fā)送

……

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

思維導(dǎo)圖

老三說：這一部分評(píng)審的時(shí)候一定要拉上產(chǎn)品經(jīng)理或者相關(guān)的業(yè)務(wù)方，確定功能點(diǎn)沒有錯(cuò)漏。

4.2.設(shè)計(jì)指標(biāo)

1. 性能要求

• 百萬級(jí)消息分鐘級(jí)發(fā)送完成
• xx接口，性能指標(biāo)：單機(jī)1000并發(fā)，95%響應(yīng)<=200ms

……

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

2. 可用性

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

……

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

3. 擴(kuò)展性

• 采用策略模式+配置，新增消息渠道，只需少量代碼+代碼即可實(shí)現(xiàn)
• 引入規(guī)則引擎，同一消息類型的不同渠道，可以通過規(guī)則調(diào)整，無需發(fā)版

……

老三說：這一部分也是設(shè)計(jì)中應(yīng)當(dāng)考慮的，不能一味求快，否則很容易堆屎山。

4. 兼容性

• 接口xxx向前兼容app 1.9.0版本，低版本需強(qiáng)制更新

……

老三說：C端系統(tǒng)的開發(fā)，有時(shí)候比較麻的是低版本app的兼容，盡可能早期設(shè)計(jì)的時(shí)候，就考慮可能的擴(kuò)展，如果實(shí)在沒法兼容，那就只能app強(qiáng)制更新，當(dāng)然這種用戶體驗(yàn)就非常不好了。

5. 可觀測性

• 接入Prometheus和Grafana，對(duì)服務(wù)和業(yè)務(wù)進(jìn)行監(jiān)控

• 服務(wù)監(jiān)控：通過控制面板觀察服務(wù)的內(nèi)存、CPU、JVM、接口QPS、接口RT……
• 業(yè)務(wù)監(jiān)控：通過埋點(diǎn)上報(bào)，收集用戶觸達(dá)數(shù)據(jù)，通過面板可以分設(shè)備、渠道查看用戶觸達(dá)成功率……

老三說：這一部分也很重要，我們一般上班的第一件事，就是看監(jiān)控面板，分析有沒有什么異常的地方。服務(wù)的可觀測性，一般公司都是用一些開源的或者付費(fèi)的監(jiān)控平臺(tái)，大廠一般都會(huì)自研監(jiān)控平臺(tái)。服務(wù)的監(jiān)控很多是通過插樁來實(shí)現(xiàn)，業(yè)務(wù)的監(jiān)控一般都需要打埋點(diǎn)。

6. 告警

• 通過PrometheusAlert實(shí)現(xiàn)服務(wù)的告警，告警信息分級(jí)別，進(jìn)行飛書通知、電話通知，告警類型分為服務(wù)告警和業(yè)務(wù)告警

• 服務(wù)告警：內(nèi)存、CPU占用過高，接口QPS過多，接口RT過長，觸發(fā)告警
• 業(yè)務(wù)告警：用戶觸達(dá)成功率過低告警

老三說：告警通常也是和監(jiān)控在一起的，畢竟開發(fā)人員也不可能二十四小時(shí)盯著告警，一般開源的、付費(fèi)的、自建的監(jiān)控系統(tǒng)，都支持配置告警規(guī)則，并通過不同的方式，郵件、短信、電話之類的渠道進(jìn)行通知。

五、概要設(shè)計(jì)

老三說：概要設(shè)計(jì)，就是做個(gè)大概的系統(tǒng)整體設(shè)計(jì)。

5.1.設(shè)計(jì)思路

• 數(shù)百萬消息段時(shí)間發(fā)送完成，流量較大，對(duì)數(shù)據(jù)存儲(chǔ)性能要求較高，需要選用高性能DB，對(duì)存儲(chǔ)壓力也比較大，同時(shí)需要一定削峰處理
• 定時(shí)/延時(shí)消息發(fā)送采用消息隊(duì)列實(shí)現(xiàn)，對(duì)MQ的消費(fèi)要求較高，并發(fā)度要高，批量消費(fèi)
• ……

老三說：這一部分主要是梳理一下整體的開發(fā)設(shè)計(jì)思路，把一些零散的想法梳理成點(diǎn)或者面，前期大家的討論可以整理在這里。

5.2.技術(shù)選型

• 存儲(chǔ)：TiDB
• 緩存：Redis
• 消息隊(duì)列：業(yè)務(wù)RocketMQ，埋點(diǎn)Kafka
• 注冊中心：Nacos
• 配置中心：Nacos
• RPC：Dubbo
• 網(wǎng)關(guān)：Gateway
• Push通道：自建

……

老三說：這一部分就是大概定一下技術(shù)選型，其實(shí)要是整個(gè)項(xiàng)目做好了選型，這一部分也可以不做，一般需要高級(jí)技術(shù)人員或者架構(gòu)師，來整體地進(jìn)行把握，當(dāng)然，很多時(shí)候選型也沒好選的，基本就是主流的那些，而且一般一個(gè)團(tuán)隊(duì)，都是統(tǒng)一的技術(shù)選型，方便維護(hù)。

5.3.業(yè)務(wù)架構(gòu)

業(yè)務(wù)架構(gòu)

老三說：這一部分就是大概對(duì)功能分分層，分分塊，把大概的功能切一切。

5.4.技術(shù)架構(gòu)

老三說：技術(shù)選型+業(yè)務(wù)架構(gòu)，其實(shí)一個(gè)大概的技術(shù)架構(gòu)就出來了。

技術(shù)架構(gòu)

老三說：技術(shù)架構(gòu)圖類型，其實(shí)也沒有特別固定的形式，主要是圖能達(dá)意，我這個(gè)圖是通過draw.io畫的，還有一些其它的還用的工具，比如大家應(yīng)該都聽過“PPT架構(gòu)師”，用PPT畫也是可以的。當(dāng)然這個(gè)圖是我隨手畫的。

5.5.系統(tǒng)環(huán)境

• JDK版本：11
• 部署環(huán)境：k8s+Containerd，單pod8核CPU+4G內(nèi)存，服務(wù)集群32個(gè)pod
• 數(shù)據(jù)庫：

• 業(yè)務(wù)數(shù)據(jù)：TiDB 64核CPU+128G內(nèi)存
• 離線數(shù)據(jù)：Hbase……

• ……

老三說：如果是項(xiàng)目初建，一般還需要對(duì)系統(tǒng)的環(huán)境進(jìn)行評(píng)估，根據(jù)技術(shù)選型、數(shù)據(jù)容量、系統(tǒng)QPS等等，來選擇系統(tǒng)的環(huán)境，這一部分一般評(píng)審的時(shí)候會(huì)拉上運(yùn)維同學(xué)，提前確定好系統(tǒng)環(huán)境，和運(yùn)維同學(xué)對(duì)齊需求和排期。

六、詳細(xì)設(shè)計(jì)

老三說：詳細(xì)設(shè)計(jì)，就是具體指導(dǎo)開發(fā)的設(shè)計(jì)部分了，包括流程啊、數(shù)據(jù)模型啊、具體用到的算法、和客戶端的接口，等等，這一部分很重要，如果沒做好，沒對(duì)齊，那么搞不好就要返工，耽誤進(jìn)度。

6.1.流程設(shè)計(jì)

• push流程

push流程

老三說：用戶觸達(dá)，業(yè)務(wù)流程基本比較簡單，對(duì)于一些交易類的，比如支付，或者B端的系統(tǒng)，比如ERP，在開始開發(fā)之前，流程一定要梳理清楚，一般通過流程圖、時(shí)序圖來描述業(yè)務(wù)流程。給大家看一下我之前對(duì)接alipay畫的簡單的時(shí)序圖：

Alipay接入時(shí)序圖

6.2.算法設(shè)計(jì)

• 渠道分流：同一消息類型，多種渠道，支持按比例分流，采用加權(quán)隨機(jī)算法實(shí)現(xiàn)
• ……

老三說：算法設(shè)置不一定數(shù)據(jù)結(jié)構(gòu)相關(guān)的算法，代碼里的一些涉及到一些需要進(jìn)行邏輯計(jì)算的，都可以稱之為算法，這一部分也可以先梳理一下。

6.3.數(shù)據(jù)模型設(shè)計(jì)

• crm_user_toutch_tash：用戶觸達(dá)任務(wù)表

老三說：數(shù)據(jù)模型設(shè)計(jì)非常重要，可以說是系統(tǒng)設(shè)計(jì)的根基，如果沒有設(shè)計(jì)好，開發(fā)和維護(hù)起來真的很痛苦，每個(gè)公司應(yīng)該都有一定的數(shù)據(jù)庫設(shè)計(jì)規(guī)范，基本就是結(jié)合業(yè)務(wù)和規(guī)范來設(shè)計(jì)了。

具體用什么工具設(shè)計(jì)呢？業(yè)務(wù)比較簡單的C端系統(tǒng)，其實(shí)直接拿表格也行，之前也試過PdMan，還行吧。

6.4.接口設(shè)計(jì)

老三說：這一部分也是重量級(jí)，但凡涉及到客戶端，或者其它服務(wù)的，這一部分都少不了，一般可以通過YApai之類的接口工具，但是建議大家還是在文檔里做個(gè)重復(fù)工作，把入?yún)⒊鰠⒅惖拿枋鲆幌拢行┑胤綐?biāo)標(biāo)重點(diǎn)，因?yàn)橛行┤苏娴牟辉趺磿?huì)看文檔。

接口設(shè)計(jì)的時(shí)候一定要和相關(guān)的同學(xué)對(duì)齊，不要怕花時(shí)間，后期改接口，是一件很痛苦的事情。

6.5.異常處理

• 系統(tǒng)中的不確定異常，進(jìn)行統(tǒng)一處理，響應(yīng)“Network Error”
• 埋點(diǎn)異步發(fā)送，不影響主要功能
• ……

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

七、風(fēng)險(xiǎn)評(píng)估

老三說：其實(shí)每一次上線都伴隨著風(fēng)險(xiǎn)，從設(shè)計(jì)，一直到上線之前，都要對(duì)存在的風(fēng)險(xiǎn)進(jìn)行評(píng)估，上線了要重點(diǎn)觀察風(fēng)險(xiǎn)點(diǎn)，也要提前設(shè)計(jì)好回滾或者處理方案，一旦發(fā)現(xiàn)不對(duì)勁，及時(shí)回滾和處理。

7.1.已知風(fēng)險(xiǎn)

• 對(duì)數(shù)據(jù)相關(guān)服務(wù)壓力較大，用戶分群、用戶畫像等數(shù)據(jù)服務(wù)崩潰風(fēng)險(xiǎn)
• MQ存在堆積風(fēng)險(xiǎn)，導(dǎo)致用戶收到消息延遲
• QPS較高，數(shù)據(jù)庫CPU飆升風(fēng)險(xiǎn)
• ……

7.2.可能風(fēng)險(xiǎn)

• 場景類消息延遲，可能會(huì)影響交易相關(guān)流程，拉低轉(zhuǎn)化率和成交率

……

八、測試建議

老三說：需求評(píng)審階段、設(shè)計(jì)評(píng)審階段，最好都拉上測試同學(xué)，測試同學(xué)要對(duì)整體的功能，還有性能，都有比較清楚的了解。但是啊，如果只看功能的話，可能就是表面的點(diǎn)點(diǎn)點(diǎn)，具體實(shí)現(xiàn)邏輯，還是開發(fā)比較清楚，所以說給測試同學(xué)提一些測試建議，給測試的測試用例提供參考。

同時(shí)，我個(gè)人覺得，從測試的角度進(jìn)行思考，也能有效減少寫代碼的bug。

8.1.功能測試

老三說：這一部分基本就是結(jié)合設(shè)計(jì)目標(biāo)的實(shí)現(xiàn)功能，列一下測試步驟和預(yù)期結(jié)果

8.2.性能測試

• xxx接口壓測，預(yù)估單機(jī)QPS1000

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

九、上線準(zhǔn)備

• 運(yùn)維搭建環(huán)境
• 數(shù)據(jù)初始化
• 添加配置
• 消息隊(duì)列創(chuàng)建
• 依賴服務(wù)上線
• 服務(wù)上線

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

十、評(píng)審及意見

老三說：設(shè)計(jì)文檔不是寫完，啪，丟出去就完事了，還要上設(shè)計(jì)評(píng)審會(huì)，評(píng)審的時(shí)候，通常相關(guān)同學(xué)會(huì)提出一些評(píng)審意見，這些都應(yīng)該記錄下來，解決完了之后，再次評(píng)審，直到評(píng)審?fù)ㄟ^，然后就可以開始CRUD了。

好了，看完這個(gè)模板，想必你對(duì)技術(shù)設(shè)計(jì)也有一定的認(rèn)識(shí)了，老三實(shí)際上沒怎么接觸過用戶運(yùn)營相關(guān)的東西，所以內(nèi)容大家隨便看看，主要看模板。

當(dāng)然模板是相對(duì)固定的，但是設(shè)計(jì)是靈活的，做技術(shù)設(shè)計(jì)的時(shí)候，也不用拘泥于固定的形式，根據(jù)具體的需求，考慮到需要考慮的點(diǎn)，能做到設(shè)計(jì)指導(dǎo)開發(fā)就夠了。

那么，假如你已經(jīng)能做好技術(shù)設(shè)計(jì)……

但是——

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

老三：可能不太……

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

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

而且——

老板：呦，三某的文檔寫的很清晰，代碼也很優(yōu)雅，今年公司績效不好，找個(gè)實(shí)習(xí)生把他替了吧。

……

繃不住

參考：

[1].用戶運(yùn)營：觸達(dá)系統(tǒng)應(yīng)該如何搭建:https://www.woshipm.com/user-research/4239618.html)

[2].一個(gè)實(shí)時(shí)精準(zhǔn)觸達(dá)系統(tǒng)的自我修養(yǎng):https://juejin.cn/post/6844904009770221581