系统稳定性

稳定性衡量标准

• 系统的各项指标相对平稳，不会有很高的突刺。
  
  • 响应时间
  • load
  • GC等
  • IO
• 系统的错误可以及时发现
  
  • 平时出现的小问题都能及时发现并及时修复，防止极少成多，集中爆发

依赖梳理

• 外部系统依赖图整理

  • 依赖哪些系统
  • 系统间的交互图
  • 系统稳定性=自身可用率 * 依赖系统1可用率 * 依赖系统2可用率 …. 依赖系统n可用率

• 对各个依赖进行分析梳理：强弱依赖

  • 依赖的方式: http，tcp等
  • 超时时间： 设置合理的超时时间
  • 强依赖:
    
    • 失败率&平均响应时间报警配置
  • 弱依赖
    
    • 失败率&平均响应时间报警配置
    • 降级配置：把该功能关闭
• 内部依赖
  
  • 减少循环依赖
  • 系统启动内存初始化依赖
  • 内部的各个调用层依赖梳理： service -> manager -> dao

代码层次结构梳理

• 各个主要部件调用都能有较好的抽象，方便统一监控和后续的替换
  
  • 外部缓存（memcache）
  • 数据库调用
  • 应用内部cache
  • 依赖系统调用
• 每个请求都生成一串唯一识别码（放入threadlocal中），然后可以在各个适配层打印出调用的上下文
  
  • 可以方便统计到一个请求对外的调用次数
  • 可以设置开关，方便开启和关闭

系统主要链路梳理

• 系统主要逻辑梳理
  
  • 数据接口
  • 页面
  • 定时任务
• 然后统计这些业务的调用链路，看能否有优化的空间
  
  • 会调用几次外部系统请求（数据库，缓存，外部系统等）
• 核心接口业务配置失败率、响应时间等相关报表和报警

合理的日志，方便后续线上排查

• 主要节点地方都需要追加日志，方便后续分析
• 合理的设置日志级别
• 设置后门可以动态调节日志级别
• 可以局部打开日志： 例如特定用户才可以看到等等

系统的GC分析

• 分析young gc， full gc的频率
• 可以分析单词请求大概使用的内存量,并针对性进行优化

报警机制

• 增加一些监控报警，可以及时收到相关错误信息
  
  • 外部依赖报警：失败率高，响应时间长等
  • 主要接口报警：主要接口的响应事情，失败率
  • 定时任务报警：执行失败等
  • 特定关键字报警：例如Exception， 特定的业务打印的严重错误等

合理的容量预估

• 单台服务器的qps，总的服务器的总qps

  • 注意有时候 系统总处理能力 ！= 单台服务器处理能力 * 服务器台数
  • 需要梳理系统的外部依赖，看外部依赖能否抗住
    
    • 数据库，缓存，外部系统等

• 分析系统qps的波峰波谷

• 最好能提前知道系统的流量激增的场景。 例如业务推广等。合理估算外部新增流量

限流

• 当流量过大的时候，可以开启并发线程数限制，保证部分请求可用.