看了一些网络上关于“稳定性”相关的文章，就不班门弄斧了，主要是个人针对这些文章的一个归纳。每个人对稳定性的理解，由于各种环境的不同导致在思考的方向上也就会有所不同，这里我逐一列举归纳。
第一篇：实战型（直接针对实际场景的总结）【参考：聊聊服务稳定性保障这些事】
涉及到两个方面：
1. 保障策略架构篇
从架构层面保障稳定性，常见的策略包括：
1.1. 限流（漏桶（速率一定）、令牌桶（可接受请求徒增））；
1.2. 降级（保障服务基本可用、保证服务的核心服务可用）；
1.3. 隔离；
1.4. 超时（业务需要的响应时间；统计服务日常的响应时间；分清主次，即分出哪些是核心服务，核心服务时间稍长）；
1.5. 重试；
1.6. 集群等。
2. 保障策略流程篇
保证稳定性策略的流程方面上分为：code review, 压测（服务器达到60-70%负载时的qps即为所求，线上qps=单机qps*机器数*0.7），灰度和监控（全方位监控；分级预警；监控真实环境）。
第二篇：整体架构层以及各链路环节的稳定性【参考：新浪微博平台稳定性体系介绍】
我理解这是一种更上层的稳定性建设，相对来说算是比较全面的了，这个可以作为稳定性建设的一个大的方案
第三篇：稳定性建设思路【参考：“稳定大于一切”专栏】
该文章是一个更新中的专栏，目前文章不多，但是思路框架可以借鉴，总体分为三步：
1. 事前防范
1.1 代码规约
1.2 变更管控
1.3 性能压测
1.4 混沌工程
1.5 风险预案
1.6 限流降级
1.7 业务隔离
2. 事中“止血”
2.1 监控告警
2.2 异常巡检
2.3 流量调度
2.4 资损防控
3. 事后诊断
3.1 系统诊断
3.2 JVM 诊断
3.3 组件诊断
3.4 在线诊断
3.5 链路追踪
3.6 RootCause
第四篇：偏向服务层次的稳定性思考与建设【参考：思考：如何保证服务稳定性？】
一、SLA!
创建的规范有如下几种：
1、研发规范、自身稳定；
2、事务中不能包含远程调用；
3、超时时间和重试次数要合理；
4、表数据操作必须double check，合理利用索引，避免出现慢查询、分库分表不走分表键；
5、没有有效的资源隔离， 避免不同业务共用一个线程池或连接池；
6、合理的系统拓扑，禁止不合理的服务依赖，能去依赖就去依赖，否则同步依赖尽量改成异步弱依赖；
7、精简的代码逻辑；
8、核心路径流程必须进行资源隔离，确保任何突发情况主流程不能受影响。
二、单服务稳定性
关键字：开关可控、单一职责、服务隔离、异常兜底、监控发现！
三、集群稳定性
关键字：系统架构、部署发布、限流熔断、监控体系、压测机制！
四、稳定性专项
关键字：预案、预热、强弱依赖、限流降级熔断、监控告警&链路追踪
五、稳定性建设
稳定性建设，就和基础技术建设一样，是一个长期迭代和不断调整的过程，业内常见的稳定性建设类型，主要有如下几种：1、容量规划
2、混沌工程
3、流量调度
4、容灾&异地多活
其中常见的容灾有如下几种：
1）缓存挂掉，集群重启缓存预热如何处理？本地缓存，多级缓存是否可以替代？
2）分布式锁，是否有开关一键切换？比如：ZK/ETCD编写的分布式锁；
3）大促峰值流量，如何防止外部ddos攻击？如何识别流量类型？
4）资源隔离：资源隔离，服务分组，流量隔离；
5）高可用思想：避免单点设计！
6）容错
5、异地多活
六、稳定性思考
关键字：阶段工作、角色转变！
第五篇、个人理解
稳定性建设，从另外一个方面来说，其实就是系统的高可用，我觉得可以转变为如何保证系统的高可用。所以这里再介绍几篇高可用的文章。
5.1. 究竟啥才是互联网架构“高可用”（58沈剑）（文章我感觉讲解的一般，但是总结互联网架构层次可以知道一下）
这篇文章主要根据互联网常见架构层次：
（1）客户端层：典型调用方是浏览器browser或者手机应用APP；
（2）反向代理层：系统入口，反向代理；
（3）站点应用层：实现核心应用逻辑，返回html或者json；
（4）服务层：如果实现了服务化，就有这一层；
（5）数据-缓存层：缓存加速访问存储；
（6）数据-数据库层：数据库固化数据存储；
六个层次进行讨论，通过每一层的“冗余+自动故障转移”来综合实现的
5.2. 监控系统选型，一篇全搞定！（这篇文章不错，从各个角度分析和讲解了监控系统的方方面面。因为上面的稳定性建设中也有几个地方提到监控系统，所以可以这里深入了解一下）
5.3. 大促场景系统稳定性保障实践经验总结（说的很笼统，大概了解一下吧）