跳转至

设计原则

业务

  1. 做一个产品，不仅仅需要完善规则，还要 把售后服务做好 。

技术

技术方案

  1. 方案可回滚，复杂需求，刷数据脚本准备好（脏数据快速修复）
  2. 大批量数据操作的风险，避免误伤到优质用户

参数校验

  1. 要做必要的参数校验
  2. 防御性编程（不要完全信任上游的入参，比如指针类型）

数据库

  1. 主键要用 int64 （int32上限是42亿）
  2. 字段注释要写明，方便新同学理解存储的数据
  3. 查询SQL上线前要进行explain，尽量要走索引
  4. 避免使用select *，尽量select field1, field2，走索引查询快
  5. 对于流水表，即使命中索引，也要尽可能batch查询
  6. 扫表操作要 select * from table where id > x and id < y and 具体条件，不要用 select * from table where 具体条件 limit x, y
  7. 刷数据时，要限流，上游不能无限重试，否则会导致 db连接池 用完，从而没法获取到新的连接进行读/写操作

缓存

  1. 热key解决方案
    • 客户端加本地缓存，LFU缓存之类的，防一下热key
    • 将热key打散，压力分摊到子key上
  2. Redis key设置了过期时间，业务上也要做时间判定
    • 内存快满了，会逐出部分key
    • 有大key / 操作复杂度大，执行完操作才会清除过期的key，会有延迟

消息队列

  1. 注意幂等处理

检索ES

TODO

日志

使用 errors 包，封装堆栈信息

  1. github.com/pkg/errors

报警

  1. 对于日常请求量波动比较大的，建议关闭小时级/天级波动报警，转而设置一个安全阈值报警，超过阈值则报警
  2. 对于一些 corner case 使用日志报警，还是很不错的。

稳定性治理

  1. 流程管控
    • 上线核心监控，静态代码检测
    • 技术方案模板，异常场景考虑，数据/接口/状态机兼容
    • 值班机制，oncall/报警/数据一致性跟进
  2. 复盘总结
    • 故障/线上问题复盘
    • 项目总结（高估分比/核心项目）
    • 值班总结，周维度oncall/报警治理/数据一致性/SLO/性能/错误码
  3. 专项治理
    • 快速发现问题：代码panic，报警治理，全链路故障感知，数据一致性对账（实时/离线）
    • 业务/系统容错：状态机容错/时效监控/最终一致性
    • 业务/系统SLA：单机故障，超时重试，mesh动态负载均衡，自动迁移POD，错误重试，强弱依赖，错误码专项，业务指标
  4. 质量宣贯
    • 总结分享：质量培训，小喇叭分享，质量提升建议分享
    • 质量考核：小喇叭/安全/质量考试