简要概述如何做好程序设计功能

功能设计流程图

与外部系统交互、本系统模块之间流程，比较好用的画圈软件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监控告警
• 业务监控，例如：发券量暴涨或暴跌、活动注册人数同比或环比异常

预案设计

设计预案减少损失

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