Backend

错误处理

• 切勿向客户端暴露堆栈跟踪——在内部记录日志，返回通用消息
• 结构化的错误响应：代码、消息、请求ID——便于调试且不泄露信息
• 对错误输入快速失败——在入口点进行验证，而非深入到业务逻辑中
• 意外错误：返回500状态码并发出警报——预期错误：返回适当的4xx状态码

输入验证

• 验证所有外部输入——查询参数、请求头、请求体、路径参数
• 白名单验证有效输入，而非黑名单禁止错误输入——拒绝未知字段
• 尽早验证，在任何处理之前——节省资源，错误信息更清晰
• 对所有输入设置大小限制——防止内存耗尽攻击

处处设置超时

• 数据库查询：设置超时，通常为5-30秒
• 外部HTTP调用：连接超时 + 读取超时——不要无限等待
• 总体请求超时——网关或中间件层面
• 后台作业：设置最大执行时间——防止僵尸进程

重试模式

• 指数退避：1秒、2秒、4秒、8秒……——防止惊群效应
• 添加抖动：随机化延迟——防止同步重试
• 为非幂等操作使用幂等键——可安全重试
• 针对故障依赖的熔断器——避免持续冲击，快速失败

数据库实践

• 连接池：复用连接——创建连接代价高昂
• 事务范围最小化——短暂持有锁
• 为读密集型工作负载使用只读副本——分离读写流量
• 始终使用预处理语句——预防SQL注入，查询计划缓存

缓存策略

• 预先确定缓存失效策略——TTL、基于事件或两者结合
• 在正确层级缓存：查询结果、计算值、HTTP响应
• 防止缓存雪崩——加锁或概率性提前过期
• 监控命中率——低命中率=资源浪费

速率限制

• 对高开销操作实施每用户/IP限制——登录、注册、搜索
• 不同操作采用不同限制——读操作与写操作
• 返回Retry-After头部——告知客户端何时重试
• 在请求管道早期进行速率限制——节省资源

健康检查

• 存活探针：检查进程是否在运行——若失败则重启
• 就绪探针：检查能否处理流量——若失败则从负载均衡器中移除
• 针对启动缓慢服务的启动探针——初始化期间不终止进程
• 健康检查应快速且低成本——避免每次探测都访问数据库

优雅关闭

• 首先停止接受新请求——排空负载均衡器
• 等待进行中的请求完成——设置超时机制
• 妥善关闭数据库连接——防止连接泄漏
• SIGTERM信号处理：优雅关闭；超时后发送SIGKILL

日志记录

• 结构化日志（JSON格式）——便于日志聚合器解析
• 每条日志包含请求ID——实现跨服务请求追踪
• 合理设置日志级别：开发环境用debug，生产环境用info/error
• 绝不记录敏感数据——密码、令牌、个人身份信息

API设计

• 从第一天就制定版本控制策略——路径方案（/v1/）或请求头方案
• 列表端点的分页——使用游标还是偏移量；包含总计数
• 一致的响应格式——所有地方使用相同的包装结构
• 有意义的状态码——创建用201，删除用204，未找到用404

安全性规范

• 密钥从环境变量或保险库获取——绝不放在代码或配置文件中
• 定期更新依赖项——使用Dependabot/Renovate自动化
• 最小权限原则——服务账户仅拥有最低必要权限
• 认证与授权分离——身份验证与权限控制区分

可观测性

• 指标：请求计数、延迟百分位数、错误率——采用RED方法
• 微服务分布式追踪——跨服务跟踪请求链路
• 基于症状告警而非原因——关注高错误率而非CPU使用率
• 运维可视化仪表板——了解常态以识别异常