功能设计流程图
与外部系统交互、本系统模块之间流程,比较好用的画圈软件draw .io或在线的process on
数据库设计
从DDD角度界限上下文、ER图、评审表结构设计是否合理,表的关联关系是否合理、是否创建索引、是否大数据量表考虑放到分片库以及分片字段设计
缓存设计
- 缓存结构是否合理 redis结构选择(string、hash、 list、set):
- 对于C端高并发接口,hash结构要慎重用,key不能用固定的key,防止key倾 斜,可以采用string结构,value尽可能压缩下,比如 {“groupId:”:“536363737”, “groupId”:“989898989”}改为"536363737#989898989",大大节省redis空间。
- 对于数据量很大,单条valve报文很大的业务,如果经常判断某个值是否存在,可以考虑采用set结构,利用sismember方法,时间复杂度O(1)
- 缓存过期时间是否合理:不能怕脑袋胡乱给一个时间,如果存放的数量,过期时间一定要给短一些,比如2日分钟或半小时,否则增长很长,打爆redis
- 缓存是否设计考虑预热和重建机制
- 缓存中尽可能不能使用delete命令;delete会阻塞redis,特别是存放数量很大的hash、set、list, 容易阻塞redis,引1发事故,替换方案:expire -1
- 是否是否设计二级缓存;本地缓存+分布式缓存,实现方式caffine或quavatredis,对于数据量不大热点数据(一般1W条以下,单条报文10kb以下,比如网点数据、航线数据)可以放本地缓存,这些热点数据查询非常频繁,容易造成redis倾斜,本地缓存可以抗这种高井发流量.
- 防穿透处理
- 提供c端的接口,查询不到数据,尽可能不要穿透到数据库,防止打爆数据库,查不到一定记得打印告營日志,及时人工千预
- 提前将数据预热到缓存中(系统启动预热或者运营后台有手动刷新缓存按钮或者有个job刷缓存)
job设计
- job逻辑要考虑幂等设计
- job逻辑尽可能轻量级,不要太重,导致执行逻辑很久(如果确实逻辑比较复杂,可以分拆job或者从代码层面优化,例如:分批井行处理、减少单次处理数据〕
- 构建数据到缓存类似的job,尽可能选择时间在晚上12点以后,尽量不要白天进行,因为白天流量很大,重建缓存容易引起接口抖动
- 对于定时执行的job,设计执行时间的时候,要慎重考虑线上整个job执行的时间,根据这个时间配置cron表达式,不要拍脑袋随意设置,
- 不然本次job没执行完,下一次job执行的时候容易错过。
- 对于大表数据(百万、千万甚至亿级),可以利用xxjob、saturn等分布式调度框架的分片处理能力,并行刷数据,提供处理速度。
接口设计
- 高并发接口必须在测试环境压测,清楚的知道接口支持的QPS,另外根据压测报告给出的优化建议,及时调整线上的配置、代码优化。
- 提供给C端的接口,要清楚曝光位省、然后根据接口可能预计调用的流量、压测的接口最大支持的QPS,决定是否扩容、是否需要限流及兜底逻镇、是否熔断
- 程序中涉及的异常信息,及时配置错误监控告警,遇事做到心中有数。
- 对于业务关键位置,及时打印info级别的业务追踪日志,如果是高并发接口,要做好开关,能秒级关闭,因为打印日志也特别耗性能。
- 程序设计方面,高井发接口,尽可能使用缓存、能异步就异步 (一般用mq,不要用多线程异步)、 尽可能采用无锁设计防止线程Lock CPU冲高,批量写库
- 接口前置逻铜提前,尽早过滤掉不合规運银,缩短接口整个调用链路时长,提升接口整体吞吐量。
- 接口要考虑无状态设计、昇等设计(考虑分布式锁唯—key)、安全设计(接口方法签名、是否接第三方防刷服务判断是否黑产用户)
无状态服务:客户端的每次请求必须具备自描述信息,通过这些信息识别客户端身份。服务端不保存任何客户端请求者信息
有状态服务: 即服务端需要记录每次会话的客户端信息,从而识别客户端身份,根据用户身份进行请求的处理,典型的设计如 tomcat 中的 session
- 对第三方服务做到零信任,考虑降级、熔断,与业务方确认好兜底逻辑处理。
- 工具类尽可能使用apache、google等出的、 一些github小众的开源框架很多在高井发场最有bug和性能瓶颈。
- 接口的时间复杂度,部分在设计的时候尽可能保证是0 (1),例如调用第三方接口,for循环调用的,是否可以提到缩环外,传多个id批量调用一次,时间复杂度从0(n)降为0(1)
监控设计
- 核心接西做好监控,例如:调用量上涨/下跌80%、接口健康度监控 (5分钟error超过100次、5分钟接口超过1s 100日次、5分钟不可用次数超过1000次)
- 应用监控,例如:应用cpu、内存层、gc、繁忙线程数、数据库连接池连接数监控告警
- 中间件监控,例如:redis可用性、cpu-内存-流量-大key-热key-慢查询监控、kafka可用性-消息积压情况-丢失率监控告警
- 数据库监控,例如:mysql cpu、慢sql监控告警
- 业务监控,例如:发券量暴涨或暴跌、活动注册人数同比或环比异常
预案设计
设计预案减少损失
- 设计全局开关(系统接近不可用,通过配置中心全局开关快速切断接口流量,保证系統可用)
- 遇到系统故障,非核心功能通过配置中心开关下线,保证整体服务可用
- 应用能自动扩容(这里就要求应用做到无状态设计,比如:我们之间有一些应用有调用加密机,但是新应用节点需要申请白名单,这种设计方式就没法自动扩容