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