随着互联网流量规模的不断壮大，对服务端稳定性保障能力提出了更高的要求，本文梳理了常用的保障思路，列举了一些规范：
- 非数据服务做到无状态，避免同一集群内的节点间有功能差异；
- 做到实例可以被随时停止、重启、增加，并且完全不依赖于本地磁盘或者内存；
- 线上服务最小集群单元2个实例，避免单点服务；(如无法避免，则应该在设计阶段考虑到单点故障的的处理方案)
- 服务的所有依赖库或者服务都要有明确的负责人，依赖需要有完备SLA；
- redis作为缓存使用，每个key都要设置默认的过期时间，强烈不建议redis作为存储使用；
- 服务需要具备故障隔离能力，依赖方异常需要有应对措施，具备自动降级/熔断能力或通过配置中心实现的快速开关能力；
- 服务之间的调用，服务调用存储层(Mysql,Redis等)需要设置合理的超时；（合理的超时可以有效防止外部服务突然耗时增加导致自身服务hang住或者资源耗尽）
- 依赖数据库的服务需要合理的设置数据库连接池；（合理的数据库连接池设置能有效保护数据库，防止连接过多耗费数据库资源）
- 业务服务每个请求默认打印一条业务日志，出现错误，必须要有错误日志；
- 服务之间通过API进行交互，禁止通过数据存储层（Redis\Mysql）进行交互(多服务共享数据库)；
- 如果存在Redis热Key，需要打散，分散开来；
- 如果存在数据库热的Update，需要打散，分散开来；
- 查看最近的SQL执行情况，慢SQL需要优化；
- 避免对数据库锁表或者锁库的操作 ；
- 调用外部服务或者存储层如果有重试的必要，需要有限的合理的重试；
- 对外接口需要设置合理的限流，防止突发流量等情况；
- 所有写操作接口必须保证幂等性，防止因重试导致的业务问题；
- 所有读操作接口必须保证性能，实时性要求不高的尽可能多的利用缓存机制；
