rpc 服务中,“业务错误”的返回应该如何设计? - V2EX
justdoit123
·
2024-07-02
·
via Coding
 |
|
7
povsister 2024 年 7 月 3 日 1
@justdoit123 粗略意义上正确,不过各家有各家的做法,rpc 的错误机制设计是要和可观测+trace+SLO 大盘联合起来考虑的。 业务错误不代表监控不需要关心,简单来说: 如果你只需要拒绝服务+返回错误,并且需要有一个自定义的 errcode 去表示这是什么类型的错误,同时附带一个简短的 readable 的说明(可以理解为 errcode 作为程序使用的描述,可以依赖 errcode 进一步执行某些程序化步骤,readable 的描述作为程序员阅读使用,方便快速识别问题),除此之外不需要向调用方传递更多的错误内容,那么就适合用 rpc error 来表示。 如果你要向调用方提供更多的关于错误的具体信息,深入绑定业务场景,那么就不适合当做 err 来处理,应该作为一个正常的 rpc 响应,此时的观测方案设计应该交由调用方手动填写 metric/log ,作为业务指标监控来看。 更深一步来说,还可以细分为业务错误(入参不合法,执行条件不满足,业务逻辑错误等等),框架及中间件错误( token 无效,malformed request ,调用超时,BBR 自适应限流,熔断错误等等),以 int64 作为 errcode 的取值范围的话,常见的方案是 0 为正常响应,errcode>0 的部分作为业务错误( eg:10001=余额不足),errcode<0 的部分作为框架及通用错误( eg:-400=请求错误/参数错误,-504=调用超时,-429=BBR 限流) rpc error 本身已经有一套错误码了,这个通常称为大码,含义可以简单认为和 http code 相同,通常作为 transport 层的可观测手段,适用对象 API 网关,SLB 等基础 L3-L7 设施 业务 errcode 通常是选择 rpc error 中的 unknown error (例如 GRPC 为 status 2 )作为可扩展对象,这个称为小码,其作用就是,在 rpc 的底层 transport 没有问题的时候,用于传递业务+业务框架的错误,主要目的用于微服务治理和更细粒度的 SLO 观测
|
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。