团队技术专家的技术设计模版，真心好用！

转眼间团队的技术专家B哥已经离职一年了我还时不时会想起他因为他留下的j技术设计模版我觉得真的很好用基本上涵盖了设计需要考虑的方方面面。接下来以一个CRM项目的用户触达模块为例给大家分享一下。一、CRM_技术设计文档_消息触达模块老三说第一部分主要说明项目或者模块的概况这一部分虽然不太重要但是是必须的。二、修订记录老三说技术设计不是一成不变的经常会随着业务的变化或者根据遇到的一些问题进行完善和优化但是每一个版本都应该留下记录和备份。三、需求/背景产品文档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配置中心NacosRPCDubbo网关GatewayPush通道自建……老三说这一部分就是大概定一下技术选型其实要是整个项目做好了选型这一部分也可以不做一般需要高级技术人员或者架构师来整体地进行把握当然很多时候选型也没好选的基本就是主流的那些而且一般一个团队都是统一的技术选型方便维护。5.3.业务架构老三说这一部分就是大概对功能分分层分分块把大概的功能切一切。5.4.技术架构老三说技术选型业务架构其实一个大概的技术架构就出来了。老三说技术架构图类型其实也没有特别固定的形式主要是图能达意我这个图是通过draw.io画的还有一些其它的还用的工具比如大家应该都听过“PPT架构师”用PPT画也是可以的。当然这个图是我随手画的。5.5.系统环境JDK版本11部署环境k8sContainerd单pod8核CPU4G内存服务集群32个pod数据库业务数据TiDB 64核CPU128G内存离线数据Hbase…………老三说如果是项目初建一般还需要对系统的环境进行评估根据技术选型、数据容量、系统QPS等等来选择系统的环境这一部分一般评审的时候会拉上运维同学提前确定好系统环境和运维同学对齐需求和排期。六、详细设计老三说详细设计就是具体指导开发的设计部分了包括流程啊、数据模型啊、具体用到的算法、和客户端的接口等等这一部分很重要如果没做好没对齐那么搞不好就要返工耽误进度。6.1.流程设计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了。好了看完这个模板想必你对技术设计也有一定的认识了老三实际上没怎么接触过用户运营相关的东西所以内容大家随便看看主要看模板。当然模板是相对固定的但是设计是灵活的做技术设计的时候也不用拘泥于固定的形式根据具体的需求考虑到需要考虑的点能做到设计指导开发就够了。那么假如你已经能做好技术设计……但是——老板三某这个需求三天能不能搞定老三可能不太……老板这个需求很急而且我不能不急你懂我的意思吧老三没问题三天够了而且——老板呦三某的文档写的很清晰代码也很优雅今年公司绩效不好找个实习生把他替了吧。……原文 https://mp.weixin.qq.com/s/aM0Em1fssCleUU1yez3u-A