稳定性的定义
外界发生变化时（如：功能的发布、服务的故障），系统能稳定的对外提供服务
稳定性的手段
管理措施
研发规范：
- 制定代码规范，上线前codereview
- 制定版本管理规范，对于代码的merge规则，版本号的管理。
上线规范：
- 避开高峰期
- 上线前告知上下游风险
- 制定回滚方案
- 线上验收机制
服务隔离
将核心服务和非核心服务分离，将经常变更的服务和稳定的服务隔离，将消耗资源的服务和非消耗资源的服务隔离。
手段：业务拆分，异步化
方式：通过以下3个维度拆分服务
- 运行时隔离：适用场景共用资源池的情况。如：服务共用一个httpclient，一个慢请求会很占用ConnectionPool的线程不释放,针对此方案我们需要提前释放资源，保证其他请求正常进行。
- 进程隔离：适用场景服务拆分，梳理整个业务，然后根据该功能是否稳定，是否是核心服务，请求量大小来综合考虑，划分成不同的服务。
- 机器隔离：使用与流量凸涨的情况，我们可以将部分流量有针对性的切到新的机器上。比如：秒杀系统，甚至是有的VIP客户
冗余
如果遇到机器故障，机房故障这种自身无法避免的情况。以上的隔离手段就会失效，这种情况我们要采用冗余的方式来处理。
当和核心服务出现问题后我们可以通过切流等方式将故障转移到没有问题的服务上。
冗余级别：
- 集群内：采取的方式是N+2，即1个提供服务，2个是冗余
集群间、或者机房间：我们应该采取的服务是N+1，但是要保证1能接住此时的流量。
服务冗余的要点做到：独立部署、无状态、冗余的副本之间没有依赖。
容灾
服务隔离和冗余已经大部分影响系统稳定性的因素，但是无法解决突发情况，如：流量暴涨、被共计等，针对此我们要制定容灾容错机制。
手段：
- 限流：自我保护的机制，对于上游调用采用多种降级措施（随机降级-简单易用）。
- 降级：功能禁用（功能降级）；采用缓存，不调用下游依赖服务（上游服务降级），个别服务消耗大量资源的停用服务（服务降级），非核心服务消耗大量数据库资源停用服务（服务降级）
演练
放火演练：检测系统稳定性，发现隐患，验证稳定性手段。
演练根据级别分为：服务演练→服务演练→机器演练→集群级别→机房级别 。（建议做机器的放火演练）
压测：明确系统瓶颈。
描述稳定性的指标
可用性指标：SLA（2个9到5个9）
故障度量：PX（P3→P0）
响应时间：time<1s→time<2s→time<3s→time>3s
服务内部调用：time<100ms→time<200ms→time<1s→time>1s
总结，稳定性一般做到99.99%已经是很成熟的系统了。