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