开发中如何做好功能设计?

一、产品需求分析、PM排期及任务分解

二、开发设计评审（研发、测试参与）
1）功能设计业务流程图（与外部系统交互、本系统模块之间流程，比较好用的画图软件draw.io或在线的process on）

2）数据库设计（ER图、评审表结构设计是否合理，表的关联关系是否合理、是否创建索引、是否大数据量表考虑放到分片库以及分片字段设计）

3）缓存设计
3.1.缓存结构是否合理（string、hash、list、set），优秀实践：
1）对于C端高并发接口，hash结构要慎重用，key不能用固定的key，防止key倾斜，可以采用string结构，value尽可能压缩下，比如
{"groupId:":"536363737", "groupId":"989898989"}改为"536363737#989898989"，大大节省redis空间。
2）对于数据量很大，单条value报文很大的业务，如果经常判断某个值是否存在，可以考虑采用set结构，利用sismember方法，时间复杂度o（1）
3.2.缓存过期时间是否合理（不能怕脑袋胡乱给一个时间，如果存放的数量，过期时间一定要给短一些，比如20分钟或半小时，否则增长很长，打爆redis）
3.3.缓存是否设计考虑预热和重建机制
3.4.缓存中尽可能不能使用delete命令，特别是存放数量很大的hash、set、list，容易阻塞redis，引发事故，替换方案：expire -1
3.5.是否是否设计二级缓存（本地缓存+分布式缓存，实现方式caffine或guava+redis),对于数据量不大热点数据（一般1w条以下，单条报文10kb以下，比如网点数据、航线数据）
可以放本地缓存, 这些热点数据查询非常频繁，容易造成redis倾斜，本地缓存可以抗这种高并发流量
3.6.防穿透处理
1) 提供c端的接口，查询不到数据，尽可能不要穿透到数据库，防止打爆数据库，查不到一定记得打印告警日志，及时人工干预
2) 提前将数据预热到缓存中（系统启动预热或者运营后台有手动刷新缓存按钮或者有个job刷缓存）

4）job设计
4.1. job逻辑要考虑幂等设计
4.2. job逻辑尽可能轻量级，不要太重，导致执行逻辑很久(如果确实逻辑比较复杂，可以分拆job或者从代码层面优化，例如：分批并行处理、减少单次处理数据)
4.3. 构建数据到缓存类似的job，尽可能选择时间在晚上12点以后，尽量不要白天进行，因为白天流量很大，重建缓存容易引起接口抖动
4.4. 对于定时执行的job，设计执行时间的时候，要慎重考虑线上整个job执行的时间，根据这个时间配置cron表达式，不要拍脑袋随意设置，
不然本次job没执行完，下一次job执行的时候容易错过。
4.5. 对于大表数据（百万、千万甚至亿级），可以利用xxljob、saturn等分布式调度框架的分片处理能力，并行刷数据，提供处理速度。

5）接口设计
5.1.高并发接口必须在测试环境压测，清楚的知道接口支持的QPS，另外根据压测报告给出的优化建议，及时调整线上的配置、代码优化。
5.2.提供给C端的接口，要清楚曝光位置、然后根据接口可能预计调用的流量、压测的接口最大支持的QPS，决定是否扩容、是否需要限流及兜底逻辑、是否熔断。
5.3.程序中涉及的异常信息，及时配置错误监控告警，遇事做到心中有数。
5.4.对于业务关键位置，及时打印info级别的业务追踪日志，如果是高并发接口，要做好开关，能秒级关闭，因为打印日志也特别耗性能。
5.5.程序设计方面，高并发接口，尽可能使用缓存、能异步就异步（一般用mq，不要用多线程异步）、尽可能采用无锁设计防止线程lock CPU冲高, 批量写库
5.6.接口前置逻辑提前，尽早过滤掉不合规逻辑，缩短接口整个调用链路时长，提升接口整体吞吐量。
5.7.接口要考虑无状态设计、幂等设计(考虑分布式锁唯一key)、安全设计(接口方法签名、是否接第三方防刷服务判断是否黑产用户)
5.8.对第三方服务做到0信任，考虑降级、熔断，与业务方确认好兜底逻辑处理。
5.9.工具类尽可能使用apache、google等出的、一些github小众的开源框架很多在高并发场景有bug和性能瓶颈。
5.10.接口的时间复杂度，部分逻辑在设计的时候尽可能保证是O（1），例如调用第三方接口，for循环调用的，是否可以提到循环外，传多个id批量调用一次，时间复杂度从
O（n）降为O（1）。

6）监控设计
6.1. 核心接口做好监控，例如：调用量上涨/下跌80%、接口健康度监控（5分钟error超过100次、5分钟接口超过1s 1000次、5分钟不可用次数超过1000次）
6.2. 应用监控，例如：应用cpu、内存、gc、繁忙线程数、数据库连接池连接数监控告警
6.3. 中间件监控，例如：redis可用性、cpu-内存-流量-大key-热key-慢查询监控、kafka可用性-消息积压情况-丢失率监控告警
6.4. 数据库监控，例如：mysql cpu、慢sql监控告警
6.5. 业务监控，例如：发券量暴涨或暴跌、活动注册人数同比或环比异常

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