京公网安备11010502063487号拦截器是 gRPC 里放日志、鉴权、限流、指标的地方。多个拦截器按什么顺序执行?能改什么?流式调用怎么办?handler panic 了会怎样?这篇逐项验证。
客户端a前 → 客户端b前 → 客户端c前 → 服务端A前 → 服务端B前 → 服务端C前 → handler → 服务端C后 → 服务端B后 → 服务端A后 → 客户端c后 → 客户端b后 → 客户端a后
在 handler 前后插入的函数:服务端拦截器包住 handler,客户端拦截器包住真正发请求的 invoker。一元和流式各有自己的类型。
(先写 Chain 后写单个)客户端x前 → 客户端y前 → 客户端z前 → 服务端X前 → 服务端Y前 → 服务端Z前 → handler → 服务端Z后 → 服务端Y后 → 服务端X后 → 客户端z后 → 客户端y后 → 客户端x后 (先写单个后写 Chain)客户端x前 → 客户端y前 → 客户端z前 → 服务端X前 → 服务端Y前 → 服务端Z前 → handler → 服务端Z后 → 服务端Y后 → 服务端X后 → 客户端z后 → 客户端y后 → 客户端x后
ChainUnaryInterceptor(A, B, C) 里 A 在最外层:A前 → B前 → C前 → handler → C后 → B后 → A后。单独用 UnaryInterceptor 设置的总是排在链的前面,和选项的书写顺序无关。
err=<nil>;客户端收到 Msg="handler 的返回值(被服务端拦截器改写)";handler 里从 ctx 取到 x-trace="t-123";客户端读到响应头 x-served-by=["interceptor"]
拦截器拿到 ctx、metadata、请求和响应对象,可以读写、改返回值、用 SetHeader 加响应头。
没带 token:code=Unauthenticated message="缺少 authorization";handler 被调用 0 次 带 token:err=<nil>;handler 被调用 1 次 客户端拦截器短路:code=ResourceExhausted;代理看到客户端发出的 HEADERS 0 个
不调用下一层就是短路:服务端鉴权失败时 handler 不会执行;客户端拦截器直接返回时请求不会发出(线上没有任何 HEADERS)。
一次服务端流(服务端发 5 条):StreamInterceptor 调用 1 次,一元拦截器 0 次;包装后统计 SendMsg 成功 5、RecvMsg 成功 1 一次双向流(来回 7 条):StreamInterceptor 累计调用 2 次;SendMsg 成功 7、RecvMsg 成功 7 再来一次 Unary:一元拦截器累计 1 次,StreamInterceptor 仍是 2 次
StreamInterceptor 每个流调用一次,而不是每条消息。要统计或检查每条消息,需要包装 ServerStream/ClientStream 的 SendMsg、RecvMsg。一元拦截器对流不起作用。
norecover 子进程退出码 2;第一行输出:panic: handler 里出错了
recover 子进程退出码 0;第一行输出:出错的调用:code=Internal message="panic: handler 里出错了"
之后的调用:err=<nil> msg="ok"(服务进程还活着)grpc-go 不会替你 recover handler 里的 panic,不处理就是整个进程退出。加一个 recover 拦截器把它变成 Internal 错误。
每端 0 个拦截器:每次调用 60.7 µs(5 轮取中位数) 每端 1 个拦截器:每次调用 60.8 µs(5 轮取中位数) 每端 10 个拦截器:每次调用 61.5 µs(5 轮取中位数)
空拦截器的开销很小(本机实测 10 层不到 1 µs);真正的成本来自拦截器里做的事。