一、产品需求澄清、pm排期和任务分解

二、开发设计评审(研发、测试参与)

（1）功能设计流程图

　　采用亿图图示梳理：系统与外部系统交互、系统模块之间流程、核心功能流程图

（2）数据库设计

　　从DDD角度界限上下文、er图、评审表结构设计是否合理、是否创建索引、数据量级别、是否需要分库分表、分布式分片

（3）缓存设计

　　1）缓存结构是否合理（string、hash、list、set）,优秀实践：

• 对于c端高并发接口，hash结构需要慎用、key不能用固定key、防止key倾斜、可以采用string结构，value尽可能压缩，尽量节省空间；
• 对应数据量很大，单条value报文很大的业务，如果经常判断某个值是否存在，可以采用set的结构，利用sismember方法，时间复杂度o(1)缓存过

　　2）缓存过期时间是否合理（要结合业务确定时间，如果数据量很大，过期时间可以设置短一些，20/30分钟，防止redis被打爆）

　　3）缓存是否需要考虑预热或者重试机制

　　4）是否设计二级缓存（本地缓存+分布式缓存），对于数据量不大的热点数据(一半一万条以下，单条报文10kb以下，比如网点数据，可以放本地缓存，这些热点数据查询非常频繁，容易造成redis倾斜，本地缓存可以抗衡这种高并发流量)

　　5）缓存穿透处理

• 提供C端的接口，查询不到数据，尽量不要穿透到数据库，防止打爆数据库，查询不到一定记得打印告警日志，及时人工干预； 2）提前将数据预热到缓存中（系统启动预热或者运营后台有手动刷新缓存按钮或者job刷新缓存）

（4）job设计

• job逻辑设计要考虑幂等性

• job逻辑尽可能轻量级，不要太重，导致执行逻辑很久（如果确实逻辑比较复杂，可以拆分job或者从代码层面优化，例如：分批并行处理、减少单词处理数据）
• 构造数据到缓存类似的job,尽可能时间要在晚上12点以后，尽量不要在白天执行，因为白天执行，重启缓存容易引起接口抖动。
• 对于定时执行的job,设计执行时间的时候，要慎重考虑线上job执行的时间，根据这个时间配置cron表达式，不要拍脑袋随意设置；
• 对于大数据（百万、千万甚至上亿），可以利用xxljob、hangfire等分布式调度框架的分片处理能力，并行刷数据，提供处理速度。

（5）接口设计

• 高并发接口必须在压测环境进行压测，清楚知道接口的qps,另外根据压测报告给出优化的建议，及时调整线上配置及进行代码优化。
• 提供给c端的接口，要清楚知道曝光的位置、然后根据接口调整可能预计调用的流量，压测接口最大支持的qps，决定是否扩容、是否需要限流及兜底逻辑、是否降级、是否熔断。
• 程序中涉及的异常信息，及时配置错误监控告警，遇事做到心中有数。
• 对于业务关键位置，及时打印info级别的业务追踪日志，如果是高并发接口，要做好开关，能秒级关闭，因为打印日志也特别损耗性能。
• 程序设计方面，高并发接口，尽可能使用缓存，能异步就异步（一般使用mq，不要使用多线程异步）、尽量使用无锁设计防止线程lock cpu冲突，批

（6）数据库

• 接口前置逻辑提前，尽早过滤不合规逻辑，缩短接口整个调用链路时长，提升接口整体吞吐量；
• 接口要考虑无状态设计，幂等性设计（考虑分布式唯一key）、安全设计（接口方法签名、是否接第三方防刷服务判断是否是黑产用户）
• 对第三方服务做到0信任，考虑降级熔断，与业务方确认好兜底逻辑处理；
• 工具类尽可能采用知名的、成熟的、有社区、持续维护的框架；
• 接口的时间复杂度，部分逻辑在设计的时候尽可能保证是0(1)，例如第三方调用接口，for循环调用的是否可以提到循环外，通过批量获取，将时间复杂度从0(n)降到0(1)

（7）监控设计

• 核心接口做好监控，例如：调用量上涨和下跌80%，接口的监控度监控（5分钟error超过100次，5分钟接口超过1秒 1000次，5分钟不可用次数从国1000次）；
• 应用监控，例如cpu、内存层、gc、繁忙线程、数据库连接池链接监控告警；
• 中间件监控，例如：redis可用性、cpu-内存-流量-大key-热key-慢查询监控、kafka可用性-消息积压情况-丢失率监控告警
• 数据库监控，例如：mysql cpu、慢sql监控告警
• 业务监控,例如：发卷量暴涨或者暴跌、活动注册人数同比或者环比异常

（8）预案设计

• 设计全局开关（系统接近不可用，通过配置中心全局开关快速切断接口流程，保证系统可用）；
• 遇到系统故障，非核心功能通过配置中心下线，保证整体服务可用；
• 应用能自动扩容（这里要求应用做到无状态设计，比如：有一些应用有调用加密机，但是新应用节点需要申请白名单，这种设计就无法做到自动扩容）