稳定性治理二，稳定性分析
目录
重新认识系统稳定性（SLA与系分）
稳定性分析（单点，容量和性能，依赖，数据保护，安全，资损，弹性能力，业务连续性，变更控制）
压测方案（引流，单点压测，全链路压测）
线上问题分析与排查思路
大厂稳定性设计系统实现案例
上一章我们讲的是使用科学方法对系统进行现状分析，快速精准掌握系统的一些核心指标数据，本章我们就根据掌握的内容对稳定性进行分析。
单点问题
硬件单点
一个应用不能部署在同一台物理机的多个虚拟机上
存储单点
数据库采用主备方式，能否在秒级进行切换，同时确保主备库不再同一个机房架构里
网络单点
参考阿里的骨干网，采用全冗余设计，进行七网隔离，线上线下隔离，弹内弹外隔离
机房单点
确保应用部署时，同城部署时要在两个机房进行部署，以便于单机房演练。
支付宝2015年发生了大规模的宕机事件，原因是杭州市萧山区某地光纤被挖断导致，为确保异地容灾、多活，后面专门进行了全链路单元化改造，整个交易链路都进行了单元化改造，并且经常在大促前夕进行单机房演练；
「“单元化”是一种架构思想，核心是：把完整的业务处理组件封装成一个单元，每个单元都能独立的处理完业务。」优势是可以支持业务无限弹性扩展的，可以突破大厂未来的业务增长导致的系统容量瓶颈。
基础中间件单点
消息中心是否存在单点，当消息有延时或丢失时，要确保业务能正常访问（需要将消息当做弱依赖，做好补偿机制）；
配置中心不能直接强依赖，例如nacos，apollo，redis 等，出现问题时，就会影响到正常业务。
数据库单点
典型的做法是先垂直拆分再水平拆分，需要解决多数据源，数据分片，访问透明问题。
内部服务访问单点
强依赖的下游接口，例如鉴权服务，登录服务等，这种接口尤其要注意，如果您系统中绕不开他们，则需要下游进行重保，以及做好失败的补偿和告警。
外部服务访问单点
外部三方提供的服务，例如银行网关，三方存储，这种无法推动改变的外部依赖，需要在调用端做好重试、补偿、告警，建立系统自愈能力减少人工干预（人为的变动也是风险）。
前端资源单点
是否有图片，js，css等静态资源单点，是否有CDN节点单点问题等
「如上这些单点问题，要解决起来是需要具备一定的财力的，现在的云计算服务，很大程度上减少了中小企业的搭建成本，可谓是养兵千日，用兵一时！」
容量评估
除了业务上的 bug，人为的事故，其他引起系统挂掉的几乎都是容量问题，主要分为两个部分：
流量上涨超出系统本身的容量
依赖服务的不稳定，导致系统本身的容量下降
评估服务的访问量与容量
给出所提供服务的访问量（QPS）；
给出单台应用服务器的稳定峰值处理能力；
根据当前部署架构中集群大小，评估峰值访问量与集群整体峰值处理能力间的关系；
评估对于内部依赖服务的访问量；
评估对于外部依赖服务的访问量
评估数据访问量，数据增长量及数据库连接池
计算服务实现中对每一个数据库的访问量（TPS）；
每日日常数据的增长记录数及存储容量；
计算承载服务的应用集群对数据库连接数的需求，确保所依赖的每一个数据库的总连接数不超过数据库的承载能力。
存储容量
本地存储请确保应用服务每天对本地磁盘的数据存取量是否会超过本地存储的容量极限，同时要确保单个文件的大小不会受到存储限制
网络流量
内部网络流量、连接数与请求数，确保不超过内部网络设备的承载能力。内部网络流量、连接数与请求数需要包含交换机、负载均衡设备、SSL设备、防火墙、专线等。通过性能压测获取阀值，根据线上服务的流量占比进行推算
消息量
需要计算服务处理对可靠消息数量与消息体大小的需求，当消息无法处理时可以根据优先级进行降级处理。
配置中心的容量
确保配置中心的容量足够，当配置中心宕机或服务不可用时，确保应用仍能正常运行。
突发性容量上涨
特点：持续时间短，请求量远大于容量，服务瞬间挂掉。表现为服务尖刺。
【解决】
限流（随机,IP,URL，如果是内部服务可以针对某系统限流，依据之前的系统分析，实施适合自己的限流策略）
“当瓶颈资源在彻底挂掉（耗光）之前，保留一点资源用来 block 新的请求”，超过的流量直接返回 Server 忙的提示
降级其他不重要的服务，例如视频播放降级弹幕服务，淘宝交易降级推荐服务等，保障重要的服务
周期性容量上涨
特点：这些流量属于正常需求的流量，用户需求不会因为格挡而消失，由于本质原因是请求量持续的大于容量，所以用户的等待时间会无限期延长，直到超过服务器的超时时间，系统挂掉。
例如做大促，做活动，会持续一段时间，可以针对性的做系统扩容。
【解决】：
提前做好容量规划，进行扩容
临时增加，借调服务器
限流，超过容量的请求快速返回失败，保证系统“不挂”
依赖治理
依赖的资源不稳定
特点：依赖资源，主要是指远程服务或存储，由于远程服务的响应时间变慢，或者挂了，直接导致整个系统的容量下降。
由公式 Threads = QPS * RT / 1000 可以得出，输入 QPS是固定的，由于 RT 的变长，则需要更多的 Threads 才能支撑输入的 QPS，所以一旦依赖资源不稳定，结果是轻易使得线程资源达到瓶颈。
用户找过来时候，肯定不能说由于xx服务不稳定导致，这些都是废话，要不你就去掉这种依赖，去不掉就保障好链路。
【解决】：
资源做线程数依赖限流，不让过多的线程堵塞在该资源上；
线程数量能根据依赖资源的服务能力进行动态控制，动态减少或增加对资源的请求数量；
服务的强弱关系，做好常规、紧急预案，确保不会发生弱依赖影响关键主业务的问题。
依赖治理
强弱依赖识别：对关键链路的应用进行调用链路的服务进行强弱依赖分析，识别出哪些是强依赖，哪些是弱依赖。
强依赖一般指此服务不可用，流程不能往下走，直接影响功能，否则为弱依赖。
强弱依赖关系梳理方式：
手工梳理
工具扫描
日志分析
「强弱依赖的治理：」
首先不合理的依赖先去除
强依赖是否是真正的核心业务依赖，如果不是，就变成弱依赖
「对于弱依赖，一般的处理方式：」
增加业务开关，紧急情况可以降级掉这个功能
增加限流，通过控制线程的数量或结合响应时间来一起控制
「服务双链路保障：」
很多只读服务默认大部分是直接依赖DB，对于前端应用的高并发、大流量访问，对于没有强一致实时性的场景，能上cache的尽量上cache(tair)
「服务分组&隔离」
服务集群本身，如果重要性和访问QPS特别大，有必要对外考虑做服务分组集群。
针对重要的应用，加入集群白名单，正常提供服务；对于其他非重要应用，新建一集群，两集群隔离互不干扰
流程机制：服务中心因为其地位的重要性，在发布机制做约束，指定发布窗口
安全
安全开发 安全编码规范（XSS、CSRF、SQL注入）
代码安全扫描（白、黑盒扫描）
账户安全
对于登录、认证等业务进行检验及通知提醒；
最小权限选择，仅能访问业务设计时规定的资源和服务；
数据安全
采用文件方式交互的数据，做双重检验；
涉及到用户手机、身份证号、邮箱等敏感信息进行脱敏；
网络安全
网络设计和部署上采用全冗余结构，具备充足带宽；
具备网络服务防攻击能力（DDOS）
资损
任何由于系统故障、缺陷、人为操作、安全漏洞导致公司或客户蒙受直接或间接损失的事件，都属于资损事件。
涉及到的内容较为复杂，具体的不展开，这里想要强调的一点就是涉及到金钱的内容，需要额外做好分析，重点保障，核对等。
弹性能力
业务监控能力 对关键路径的系统进行详细的监控，发现问题自动报警 系统级（CPU、内存、IO）监控、JVM监控、业务监控
故障隔离能力
确保故障不会从低等级系统/组件传播到高等级系统/组件
强依赖核心服务按组别进行隔离，确保不受低级别应用的影响
访问量控制能力
服务提供者要给出服务最大能承受的访问量，并做好控制
服务请求者对依赖服务进行控制，确保自身容量不受太大影响
服务降级能力 依赖服务不可用时，是否可以做降级处理，有一定的降级标准
系统容错能力 系统容错、数据库容错、关键应用容错、服务不可用容错等的设计
变更控制
项目测试环境 项目中申请的测试服务器，部署项目专用分支代码，用于测试功能与否。
日常测试环境 这个是最接近我们线上环境的测试环境，是应用要发布到线上最重要测试关卡。日常需求和项目在正式发布前，都需要把代码合并到日常环境，进行最终的功能回归及自动化回归，只有全部通过后，应用的新代码才允许部署到线上环境。
预发布环境 是线上环境的预检环境。为正式环境中不对外服务的一组机器，应用在日常测试环境测试通过后，可以要求进入预发布环境进行线上数据的功能测试。
灰度环境 对于某些新业务或重要度较高的业务，为确保上线后完全正常，可以先用内部流量进行测试，待功能完全验证通过后，再发布上线。
正式环境 即生产环境，为对外服务的环境。
本篇先到这里，下一篇是压测。欢迎关注我，一个有趣的灵魂。
本期相关稳定性治理一，重新认识系统