服务稳定性的思考

稳定性

明确业务价值

• 价值导向：飞行、驾驶，系统承载的价值
• 超载：风险与收益

梳理主链路，保证可用性

• 1、避免单点
  应用服务器、中间件、外部接口、数据库、机房
• 2、梳理强弱依赖
  强依赖:重点监控、做好降级与业务影响评估、沟通机制，重试机制
  弱依赖:记录日志，延迟补偿处理或不处理
• 3、避免不合理调用
  循环调用服务、串行调用接口过多、无效调用等
  常见的方案有：
  • 1.缓存
    量大，对数据一致性要求不高的，可以通过缓存来降低压力;多级缓存
  • 2.静态化
    一些数据如果可以通过静态化的，大促降级尽量不要通过接口
  • 3.接口
    批量、聚合，并行

快速失败、防止雪崩

• 1、超时参数
  连接各种中间件参数，如Mysql、Redis、MQ、接口等，不要出现雪崩；
  服务之间调用需要保证超时时间，现在最新的方案是逐层动态计算，即一个接口要串联调用5个服务，总的超时时间设置为5秒，在调用第一个服务后还剩下4.8秒，则在调用第2个服务的时候会把4.8作为超时时间传下去
• 2、限流
  数据源：可以在接入层上限流
  服务保护:流量控制、集群限流、热点限流、自适应限流等可以用Hystrix进行保护
• 3、熔断
  外部依赖可降级熔断保护，根据可用率、TP999等
  ##削峰或错峰
  访问量特别大，就需要采用削峰了
• 1、验证码
• 2、排队
• 3、延迟

Checklist

根据压测调整线上参数、机器、监控等

预案

提前做故障预案快速止损

• 1、可执行
  小工具、提单准备跑数等sql,开关等
• 2、责任到人
  操作步骤到人、到某个页面、某个参数等
• 3、覆盖核心场景
  可知的：按预案执行
  不可知的：按现象评估执行降级

问题同步

做到及时同步，影响不一定只是单点的，防止扩散，及时止损