本文共 612 字，大约阅读时间需要 2 分钟。

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.上下游依赖梳理与限流

死道友不死贫道的做法，避免下游对接口的滥用导致服务出现问题，故需要梳理清楚依赖关系并适当进行限流。

限流需设置告警并周知下游

转载地址：http://wriob.baihongyu.com/