系统稳定性
稳定性衡量标准
- 系统的各项指标相对平稳,不会有很高的突刺。
- 响应时间
- load
- GC等
- IO
- 系统的错误可以及时发现
- 平时出现的小问题都能及时发现并及时修复,防止极少成多,集中爆发
依赖梳理
外部系统依赖图整理
- 依赖哪些系统
- 系统间的交互图
- 系统稳定性=自身可用率 * 依赖系统1可用率 * 依赖系统2可用率 …. 依赖系统n可用率
对各个依赖进行分析梳理:强弱依赖
- 依赖的方式: http,tcp等
- 超时时间: 设置合理的超时时间
- 强依赖:
- 失败率&平均响应时间报警配置
- 弱依赖
- 失败率&平均响应时间报警配置
- 降级配置:把该功能关闭
- 内部依赖
- 减少循环依赖
- 系统启动内存初始化依赖
- 内部的各个调用层依赖梳理: service -> manager -> dao
代码层次结构梳理
- 各个主要部件调用都能有较好的抽象,方便统一监控和后续的替换
- 外部缓存(memcache)
- 数据库调用
- 应用内部cache
- 依赖系统调用
- 每个请求都生成一串唯一识别码(放入threadlocal中),然后可以在各个适配层打印出调用的上下文
- 可以方便统计到一个请求对外的调用次数
- 可以设置开关,方便开启和关闭
系统主要链路梳理
- 系统主要逻辑梳理
- 数据接口
- 页面
- 定时任务
- 然后统计这些业务的调用链路,看能否有优化的空间
- 会调用几次外部系统请求(数据库,缓存,外部系统等)
- 核心接口业务配置失败率、响应时间等相关报表和报警
合理的日志,方便后续线上排查
- 主要节点地方都需要追加日志,方便后续分析
- 合理的设置日志级别
- 设置后门可以动态调节日志级别
- 可以局部打开日志: 例如特定用户才可以看到等等
系统的GC分析
- 分析young gc, full gc的频率
- 可以分析单词请求大概使用的内存量,并针对性进行优化
报警机制
- 增加一些监控报警,可以及时收到相关错误信息
- 外部依赖报警:失败率高,响应时间长等
- 主要接口报警:主要接口的响应事情,失败率
- 定时任务报警:执行失败等
- 特定关键字报警:例如Exception, 特定的业务打印的严重错误等
合理的容量预估
单台服务器的qps,总的服务器的总qps
- 注意有时候 系统总处理能力 != 单台服务器处理能力 * 服务器台数
- 需要梳理系统的外部依赖,看外部依赖能否抗住
- 数据库,缓存,外部系统等
分析系统qps的波峰波谷
- 最好能提前知道系统的流量激增的场景。 例如业务推广等。合理估算外部新增流量
限流
- 当流量过大的时候,可以开启并发线程数限制,保证部分请求可用.