订单->用户->支付 某个服务 A 被短时间内 RPC 调用次数太多,例如 /getUser read time out 了,然后就一层层 大量的报错,(然后手动重启...)
暂时解决, 每个服务 在多台服务器部署多个(不同端口 起多个 jar,例如服务 A 在每个服务器都起一个,然后指向同一个注册中心), RPC 请求服务 A 的 /getUser 会被分到不同的服务中(具体怎么分,我不清楚), 虽然解决了,但还是偶有报错.
看到了服务熔断 /降级的博客文章, 想请教下大佬们 一般是怎么做的?
 |
1
DoctorCat Feb 28, 2021
你既然都说用了熔断措施了，那么问题我觉得不在于熔断如何进行，而是：
针对这个熔断问题，站在业务方角度来看根本问题是：为何接口 timeout 了呢？ 针对这个 timeout 问题，站在 SLA 和客户体验角度来看，熔断后服务暂时不可用，最坏的打算是什么？如何告知 or 呈现给客户？如何快速的恢复服务？ |
 |
2
wuzhizuiguo OP @DoctorCat time out 是因为访问量太大了,调用不过来,服务它自身给 time out 了.
timeout,会收到短信,我们就上去重启下... 不知道怎么控制, 又不能停止访问调用(真停了就是很尴尬,只能快点处理). |
 |
3
zhgg0 Feb 28, 2021  1
如果你这个接口是核心不可降级的接口，加上熔断措施也解决不了你的问题，本质还是要提升单实例性能和横向扩容。如果不是对实时性要求非常强的查询接口可以加缓存，在超出承受范围时走缓存或者降级逻辑。
|
 |
4
xuanbg Feb 28, 2021
网断了 timeout 了怎么办？所以该怎么办就怎么办。
|
 |
5
markgor Feb 28, 2021 1
@wuzhizuiguo
熔断只是防止影响前链路上的业务，你现在已经达成了。 我觉得你该考虑的不是降级，而是升级了.... 一般降级是作用于：request->redis->mysql; 当 redis 挂了，降级后请求直接跑 mysql 。(形容的可能不准确，但就是这个意思。 之前看过文章介绍，现在找不到链接。 大致上是： 压测拿个临界值， 达到 80%的时候横向扩展这个服务， 降回来的时候释放这个服务.... |
|
6
DoctorCat Feb 28, 2021 1
@wuzhizuiguo 既然不能停，只是告警也不能解决问题呀，那么先解决扩容问题吧，服务容量水位低于 80%+ 就要继续扩容了。如果碍于经费或者其他资源限制，那么赶紧优化代码吧。没别的解法。
|
 |
7
GreyYang Feb 28, 2021 1
先上个健康检查, 出问题了 auto restart. 如果重启一下就能好, 整几个做负载均衡, 谁停了自动重启谁, 业务面可能无感. 听说过有项目生产环境中业务周期崩溃但是能通过自动重启恢复, 上线大半年了才发现有这问题...
|
 |
8
larve Mar 1, 2021 1
那就是服务 A 的负载太大了,先在测试环境压测下服务 A 的承载上限吧
1. 根据调用量推测节点数量,多节点部署,横向提高负载能力;但这种若是瓶颈在数据库,这种扩展节点就没啥作用 2. 结合优化工具,优化服务 A 高频调用接口 |
Select Language