拦截器

概述

构建 gRPC 服务的核心是实现 RPC 方法。但有些功能独立于正在运行的方法，应适用于所有或大多数 RPC。拦截器非常适合这项任务。

何时使用拦截器

您可能已经熟悉拦截器的概念，但可能习惯称它们为“过滤器”或“中间件”。拦截器非常适合实现不特定于单个 RPC 方法的逻辑。它们也易于在不同客户端或服务器之间共享。拦截器是扩展 gRPC 的重要且常用方式。您可能会发现某些所需功能在更广泛的 gRPC 生态系统中已经作为拦截器提供。

拦截器的一些示例用例包括

• 元数据处理
• 日志记录
• 故障注入
• 缓存
• 指标
• 策略执行
• 服务端身份验证
• 服务端授权

如何使用拦截器

拦截器可以在构建 gRPC 通道或服务器时添加。然后，该拦截器将针对该通道或服务器上的每个 RPC 进行调用。客户端和服务器端的拦截器 API 不同，因此拦截器将是“客户端拦截器”或“服务器拦截器”。

拦截器本质上是按调用进行的；它们不适用于管理 TCP 连接、配置 TCP 端口或配置 TLS。虽然它们是大多数定制的适当工具，但并非所有情况都适用。

拦截器顺序

当使用多个拦截器时，它们的顺序很重要。您需要确保了解 gRPC 实现执行它们的顺序。将拦截器视为位于应用程序和网络之间的一条线上很有用。有些拦截器会“更接近网络”，对发送内容有更多控制权；而另一些拦截器则会“更接近应用程序”，可以更好地了解应用程序的行为。

假设您有两个客户端拦截器：一个缓存拦截器和一个日志拦截器。它们应该以什么顺序排列？您可能希望日志拦截器更接近网络，以便更好地监控应用程序的通信并忽略缓存的 RPC。

flowchart LR
APP(Application) --> INT1
INT1(Caching\nInterceptor) -->|Cache miss| INT2
INT2(Logging\nInterceptor) --> NET
NET(Network)

或者您可能希望它更接近应用程序，以了解应用程序的行为并查看它正在加载哪些信息。

flowchart LR
APP(Application) --> INT2
INT1(Caching\nInterceptor) -->|Cache miss| NET
INT2(Logging\nInterceptor) --> INT1
NET(Network)

您只需更改拦截器的顺序即可在这两种选项之间进行选择。

语言支持