今年夏天AWS挂了11小时，官方通报多处光缆因道路业务施工被挖断，我清晰的记得那是6.2，因为6.1带娃一天，第二天半夜报警就一直没断过。后面工程师一顿操作，然而网络问题太致命，最终无法挽回，用户也着急，公司是不是跑路了，这次问题太严重，后来做出了双机房。

当然这种case太极端了，流量攻击，DB慢查，接口超时，redis打满等才是研发常见的问题，在公司稳定性项目上断断续续做了一年，我整理了一份提高稳定性的思路供大家参考。

一 容量规划

---

1 容量目标：DID原则 - Design(D)设计20倍的容量；Implement(I)实施3倍的容量；Deploy（D）部署1.5倍的容量，根据DID指导原则，线上部署3倍当于当前流量，随着规模的扩张与收缩可以调整容量。

2 容量摸底：可以根据压测报告，或者根据当前服务cpu 内存使用率评估当前服务可以承受的容量，容量不足时需要扩容。

二 服务治理

---

1 隔离

内网外网服务隔离，比如一个服务既提供内网服务又提供外网服务就有风险，因为外网服务比较暴露被攻击的可能性比较大。

核心服务与非核心服务隔离，一般核心服务的改动少，非核心服务改动多，隔离开来有助于提高核心服务的稳定性。

2 超时

超时也是常见的坑，比如底层服务超时能引起大规模服务雪崩，mq,db,redis,http,rpc等远程调用都要考虑超时。已http为例，sockettimeout, connectTimeout，connectRequestTimeout 3个超时时间都要设置合适的超时，可以参照容量规划设置超时大小，或者参照当前rt99线来设置超时大小。

3 限流

恶意攻击或上游异常调用都能造成流量异常，常见的限流利器RateLimiter，Sentinel都是不错的选择。

4 熔断

比如调用下游服务异常，这时候如果继续调用一方面继续异常对业务没有帮助，一方面还会增加下游的服务压力，这时候可以引入hystrix就能提供较完整的解决方案。

5 定期压测

定期压测可以让你更清楚的了解当前系统的变化趋势。

三 数据治理

---

1 db

首先要数据收口，这样数据的及时性，一致性就有所保证

读写分离 当前也有很多方案比如spring读写分离和一些开源框架

合理使用索引 ，缓存

慢查询优化，分页数据没有限制，大事务引起延迟，表大了就要考虑分表了（五千万数据，还在快速增长中）

2 redis

过期 过期 过期一定要设置，可能那天redis内存打满，太恐怖。。。

kv内容过大导致内存压力，比如集群模式如果有热key导致集群压力不均匀

四 监控报警

硬件监控 业务监控 及对应报警

五 上线质量

---

可以考虑晚上交付流程保证质量

设计阶段 做什么****，搭建灰度环境，回滚方案等

ps 上线时看日志能大大提高上线质量，比如一个开发上线第一批机器都挂了还上线其他机器，你品，你仔细品。

持续更新中