大家好，我是老三。一转眼，团队的技术专家B哥已经离开一年了。我现在还时不时想起他，因为他留下的j技术设计模板确实不错。它基本上涵盖了设计需要考虑的所有方面。下面以某CRM项目的用户触控模块为例与大家分享。1.CRM_技术设计文档_MessageReachModuleProjectNameCRMSystemProjectLeader三分邪模块名UserReachModuleModuleLeader三分邪说：第一部分主要说明项目或模块的概况，这部分虽然不是很重要，但是必要的。2.修改记录版本修改人修改内容修改日期V1.0三分邪创2022-12-23老三说：技术设计不是一成不变的，经常会随着业务的变化而变化，或者根据遇到的一些问题进行改进优化,但每个版本都应该被记录和备份。3、需求/后台产品文档：为了实现用户的精细化操作，xxxx通过各种渠道向用户发送消息……老三说：这部分是结合产品文档，简单提炼需求/背景。必须，但不是重点。四、设计目标第三条说：设计目标一般分为两部分：实现功能：这部分是分析需求，把产品文档里面的东西拆解成一个个的功能，也就是CRUD。设计指标：CRUD也不一样，随便写一个shuttle就可以实现功能，但是我们的CRUD也是要有一点追求的，而且对于C端用户的系统基本上都有一些性能和易用性的要求，比如界面平均响应时间小于几毫秒，单机QPS1000，系统可用几个9...4.1．实现功能，通过多种渠道向用户推送消息，主要包括站内和站外两部分：站内：站内、弹屏、站外：邮件和短信推送微信...达到任务管理支持定时/延时消息发送，支持触发消息发送，支持用户群发……老三说：如果功能点比较多，这部分也可以用思维导图的形式来组织。思维导图老三说：这部分review的时候，一定要有产品经理或者相关业务方的参与，确保功能点没有错误或者遗漏。4.2.设计指标性能要求分钟发送百万条消息，xx接口完成。性能指标：单机1000并发，95%响应<=200ms...老三说：一般C端的服务对性能要求比较严格。毕竟，如果系统响应慢，用户的流失率就会变高。当然，用户的触达主要在于推送，用户的主动查询会少一些，消息的推送通常对速度有要求。比如有个网红，想九点在app上直播。一推，要求消息尽快推送给每个用户。不能说有的用户要到十二点直播结束才会收到消息。可用性达到模块99.9%可用性消息推送成功率80%以上……老三说：C端系统的可用性更重要。毕竟，再过一段时间，受影响的用户可能就数以万计。所以在设计的时候，还要考虑可用性，分析系统的瓶颈在哪里，流量突然上来，哪里可能承受不住，是扩容，还是限流熔断降级...可扩展性采用策略模式+配置，新的消息通道只需要少量代码+代码即可引入规则引擎，同一消息类型的不同通道可以通过规则进行调整，无需发布版本。老三说：这部分在设计时也要考虑，不能一味追求速度，否则很容易堆起屎山。兼容接口xxx向前兼容1.9.0版本的app，低版本需要更新...老三说：C端系统的开发有时候更难兼容低版本的应用程序。在尽早设计时，应该考虑可能的扩展。如果实在不兼容，只能强制更新应用。当然，这种用户体验是非常糟糕的。可观察性接入Prometheus和Grafana对服务和业务进行监控服务监控：通过控制面板观察服务内存、CPU、JVM、接口QPS、接口RT……业务监控：通过埋点上报收集用户触摸数据，通过面板，可以按设备和渠道查看用户的成功率……老三说：这部分也很重要。通常我们上班第一件事就是看监控面板，分析有没有异常。对于服务的可观测性，公司一般会使用一些开源或者付费的监控平台，大公司一般会开发自己的监控平台。很多服务都是通过instrumentation来监控的，业务监控一般都需要嵌入。Alarms通过PrometheusAlert实现服务告警。告警信息分级，飞书通知和电话通知。告警类型分为业务告警和业务告警。业务告警：内存和CPU使用率过高，接口QPS过大，接口RT过长，触发告警业务告警：用户到达告警成功率太低。老三说：报警一般都是和监控联系在一起的。所有监控系统均支持配置报警规则，通过邮件、短信、电话等不同渠道通知。5.Outlinedesign老三说：Outlinedesign就是做一个粗略的整体系统设计。5.1.设计思路一段时间内发送百万条消息，流量大，对数据存储性能要求高。需要高性能的DB，存储压力也比较大。同时需要一定的削峰处理定时/延时消息发送由消息队列实现，对MQ消费要求高，并发度高，批量消费。。。老三说:这部分主要是梳理整体的开发设计思路，将一些零散的思路整理成点或者面。在早期阶段，所有讨论都可以在这里组织。5.2.技术选择存储：TiDB缓存：Redis消息队列：业务RocketMQ，嵌入式Kafka注册中心：Nacos配置中心：NacosRPC：Dubbo网关：GatewayPush通道：自建...老三说：这部分是粗略确定技术选型，其实如果做了整个项目的选型，这部分可能就不用做了。一般需要高级技术人员或架构师对其进行整体把握。当然很多时候选型不好选，基本都是主流。那些，一般是一个团队，都是统一的技术选型，容易维护。5.3.业务架构业务架构老三说：这部分就是把功能粗略的分层，分块，把通用的功能都切成块。5.4.技术架构老三说：技术选型+业务架构，其实一个通用的技术架构就出来了。技术架构老三说：技术架构图的类型其实没有固定的形式，主要是图能表达意思。这个图是我通过draw.io画的，还有一些其他的工具还在用。听说过“PPT架构师”，用PPT画画也是可以的。当然，这张图是我画的。5.5.系统环境JDK版本：11部署环境：k8s+Containerd，单pod8核CPU+4G内存，服务集群32个pod数据库：业务数据：TiDB64核CPU+128G内存离线数据：Hbase…………第三表示：如果是项目初期建设，一般需要对系统环境进行评估，根据技术选型、数据容量、系统QPS等来选择系统环境，而这部分一般会涉及运维和检修期间维护学生。提前确定系统环境，与运维同学对接需求和进度。6、详细设计老三说：详细设计就是具体指导开发的设计部分，包括流程、数据模型、使用的具体算法、客户端接口等，这部分非常重要。如果做的不好，如果没有对齐，那么可能就需要返工，耽误进度。6.1.流程设计推送流程老三说：业务流程在用户触手可及的情况下，基本上是比较简单的。对于一些交易，比如支付，或者B端系统，比如ERP，在开始开发之前，必须先梳理流程。业务流程通常通过流程图和顺序图来描述。先给大家看一下我在连接支付宝之前画的简单时序图：支付宝接入时序图6.2。算法设计通道分发：同一个消息类型，多个通道，支持按比例分发，使用加权随机算法来实现...第三说：算法设置不一定是与数据结构相关的算法。有些代码涉及一些逻辑计算，可以称为算法。这部分也可以先梳理一下。6.3.数据模型设计crm_user_toutch_tash:用户触摸任务表字段描述数据类型id主键biginttask_no任务号bigintcomment描述varchar...老三说：数据模型设计很重要，可以说是系统设计的基础，如果设计不好，开发维护和维护真的很痛苦。每个公司都应该有一定的数据库设计规范，基本上是结合业务和规范来设计的。使用什么工具进行设计？对于业务比较简单的C端系统，其实可以直接使用表单。之前试过PdMan，没问题。6.4.界面设计界面名称添加支付任务界面文档地址https://yapi.com/xxxEnterPartInPartDescriptioncomment:TaskDescriptionOutPartOutPartDescription老三说：这部分也很重要，但是任何给客户，或者其他服务，这部分是必不可少的。一般可以使用YApai等接口工具，但建议在文档中做一个重复的工作，描述输入输出参数。有些地方标出了Emphasis，因为有些人真的不知道怎么看文档。在设计界面的时候，一定要和相关的同学对齐。不要害怕花时间。后期改接口是一件很痛苦的事情。6.5.异常处理系统中的不确定异常统一处理，异步发送“NetworkError”的响应，不影响主要功能……老三说：异常处理也是需要考虑的地方，这异常可以被吞掉降级，什么不能处理，怎么展示给客户端，怎么记录，这些都需要考虑。7、风险评估老三说：其实每一次发射都是伴随着风险的。从设计到推出前，都必须评估现有的风险。上线后，要重点观察风险点，提前设计回滚或回滚。解决方案，一旦发现有问题，及时回滚处理。7.1.已知风险给与数据相关的服务带来很大压力。存在用户分组、用户画像等数据服务崩溃风险。MQ存在堆积风险，导致用户接收消息QPS高延迟，数据库CPU飙升风险...7.2.可能出现的风险场景消息延迟可能会影响交易相关流程，降低转化率和成交率...8.测试建议老三说：在需求评审阶段和设计评审阶段，最好邀请测试同学，测试同学一定要对整体的功能，以及性能，有一个比较清晰的认识。但是啊，如果只看功能的话，可能表面上有点。具体实现逻辑在开发中还是比较清晰的，所以给测试同学一些测试建议，为测试测试用例提供参考。同时个人认为站在测试的角度思考也能有效减少写代码的bug。8.1.FunctionalTest功能测试步骤ExpectedResultTimingMessageSendingCreateTimingMessageMessageTimingSending...老三说：这部分基本上结合了设计目标的实现功能，列出了测试步骤和预期结果8.2．PerformanceTestxxx接口压力测试，估计单机QPS1000部分基本都是压力测试。很多时候，系统压力测试并没有那么简单，尤其是当链路很长的时候。9、上线，准备运维，搭建环境，初始化数据，添加配置消息队列，创建依赖服务，上线，上线。列出你做过的事情，你知道你有没有经历过“测试环境凶猛如虎，一上线就卡在原地”？可能是上线的准备没做好，少了点什么，少了点什么。10.审核意见提出审核意见的人提出解决意见的日期，提出解决意见的人提出解决日期。xxx接口需要考虑兼容性。建议将xx字段从对象更改为列表。老六，2023年1月1日，修改字段类型。老三，2023年1月1号……老三说：设计文档没写完，直接扔出去，完了，还得去设计评审会。在复习过程中，通常相关同学会提出一些复习意见，并记录下来并解决。之后再review，直到review通过，就可以开始CRUD了。好了，看完这个模板，你一定对技术设计有了一定的了解。其实老三接触用户运营相关的东西还不多，所以大家可以看一下内容，主要是看模板。当然，模板相对固定，但设计灵活。做技术设计时，不必拘泥于一种固定的形式。根据具体需求，考虑到需要考虑的点，能够设计和指导开发就可以了。好吧，如果你已经可以做好技术设计了……但是——老板：三某，这个需求三天能搞定吗？老三：可能不行……老大：这个需求很急，我得赶时间，你明白我的意思吗？老三：没问题，三天就够了！还有——老大：哟，三某的文档写的很清楚，代码也很优雅。今年公司业绩不好，找个实习生顶替他。...忍不住参考：[1]。用户操作：触摸系统应该如何搭建：https://www.woshipm.com/user-research/4239618.html)[2]。一个实时精准触控系统修真：https://juejin.cn/post/6844904009770221581
