RPC 调用过多导致 Hystrix 熔断了接口 timeout 了怎么办

[wuzhizuiguo]

订单->用户->支付 某个服务 A 被短时间内 RPC 调用次数太多,例如 /getUser read time out 了,然后就一层层 大量的报错,(然后手动重启...)

暂时解决, 每个服务 在多台服务器部署多个(不同端口 起多个 jar,例如服务 A 在每个服务器都起一个,然后指向同一个注册中心), RPC 请求服务 A 的 /getUser 会被分到不同的服务中(具体怎么分,我不清楚), 虽然解决了,但还是偶有报错.

看到了服务熔断 /降级的博客文章, 想请教下大佬们 一般是怎么做的?

[DoctorCat]

你既然都说用了熔断措施了，那么问题我觉得不在于熔断如何进行，而是：
针对这个熔断问题，站在业务方角度来看根本问题是：为何接口 timeout 了呢？
针对这个 timeout 问题，站在 SLA 和客户体验角度来看，熔断后服务暂时不可用，最坏的打算是什么？如何告知 or 呈现给客户？如何快速的恢复服务？

[wuzhizuiguo]

@DoctorCat time out 是因为访问量太大了,调用不过来,服务它自身给 time out 了.
timeout,会收到短信,我们就上去重启下... 不知道怎么控制, 又不能停止访问调用(真停了就是很尴尬,只能快点处理).

[zhgg0]

如果你这个接口是核心不可降级的接口，加上熔断措施也解决不了你的问题，本质还是要提升单实例性能和横向扩容。如果不是对实时性要求非常强的查询接口可以加缓存，在超出承受范围时走缓存或者降级逻辑。

[xuanbg]

网断了 timeout 了怎么办？所以该怎么办就怎么办。

[markgor]

@wuzhizuiguo
熔断只是防止影响前链路上的业务，你现在已经达成了。
我觉得你该考虑的不是降级，而是升级了....
一般降级是作用于：request->redis->mysql; 当 redis 挂了，降级后请求直接跑 mysql 。(形容的可能不准确，但就是这个意思。


之前看过文章介绍，现在找不到链接。
大致上是：
压测拿个临界值，
达到 80%的时候横向扩展这个服务，
降回来的时候释放这个服务....

[DoctorCat]

@wuzhizuiguo 既然不能停，只是告警也不能解决问题呀，那么先解决扩容问题吧，服务容量水位低于 80%+ 就要继续扩容了。如果碍于经费或者其他资源限制，那么赶紧优化代码吧。没别的解法。

[GreyYang]

先上个健康检查, 出问题了 auto restart. 如果重启一下就能好, 整几个做负载均衡, 谁停了自动重启谁, 业务面可能无感. 听说过有项目生产环境中业务周期崩溃但是能通过自动重启恢复, 上线大半年了才发现有这问题...

[larve]

那就是服务 A 的负载太大了,先在测试环境压测下服务 A 的承载上限吧
1. 根据调用量推测节点数量,多节点部署,横向提高负载能力;但这种若是瓶颈在数据库,这种扩展节点就没啥作用
2. 结合优化工具,优化服务 A 高频调用接口