1.全服务需进行http/rpc压测，并适当进行机器扩容
1）计算单实例下机器可承受的最大qps
压测结果以服务器实际接收到的qps为准，如下图
在单接口qps50时，服务延迟逐渐升高，故取40qps时服务器实际接收到的qps作为单实例稳定运行qps值。此时服务器实际接收的qps为91（单接口50，其余接口根据转换比设置，故总qps会大于50，并且部分发出的qps可能因为网络延迟丢失，所以取服务器实际接收到的qps为准）
2）实例扩容至 2✖️实例数✖️压测qps>线上当前峰值总qps
2.熔断时间设置
查出每个接口的TP999峰值，单独设置每个接口的熔断时间设置为该值*2
3.慢查询治理
慢查询会拖垮整个系统的性能，可通过优化sql、缓存等方案进行治理
我们服务慢查询治理后的效果
4.服务巡检
大多数错误会因为报警阈值的触发而被发现，也有少部分问题需要服务巡检去观察。
所以需要定时对系统进行服务巡检，可以发现很多问题，比如某段时间请求数每天都在暴涨，如果不是业务的扩长，就要考虑你的接口是不是被攻击了，或者有没有人在没告知的情况下就接入了你的接口之类的。
举例可观察的值如：
1.服务总请求数
2.请求错误数
3.慢查询数
4.CPU峰值
5.内存使用
6…
5.上下游依赖梳理与限流
死道友不死贫道的做法，避免下游对接口的滥用导致服务出现问题，故需要梳理清楚依赖关系并适当进行限流。
限流需设置告警并周知下游