概述

在前面 4 章我们已经从零开始编写了 Grpc 的服务端和客户端,并且还加上了认证功能以及客户端失败重试等特性。在第 3 篇和第 4 篇我们都是介绍如何使用 Interceptor 的,但是我们也仅仅是使用,在使用完前面的 Server 端和 Client 端的 Interceptor 之后,可能很多同学已经迫不及待得想知道 Interceptor 要怎么实现了,并且已经有了好几个自己想实现得 Feature 了。是的,我了解的,因为我刚看到的时候也是激动不已,恨不得马上重构一波,实现几个自己的 Interceptor,然而玩着玩着发现已经有很多现成的实现了,还需要自己写?

但是,无妨,既然现在还没有很恰当的时机来实现,不妨先看一下怎么实现呗,万一哪天就用上了呢?或者哪天别人的 Interceptor 暴 Bug 了,我们还是知道怎么定位的嘛。

分类

在开始介绍如何实现之前,还是要知道一个前提的,那就是 Interceptor 是有分类的,可以横向纵向分为 4 类,这么看:

unary stream
server client

这里虽然还没有介绍 Stream,但是没关系,先记住它就好了,所以这里需要考虑这几种情形,但是,原理上都是一致的,所以我就以其他一个作为示例,就不纠结所有都示范一遍了。

实现 Interceptor

这里我的目标是自己实现一个 Dump 请求和响应的 Interceptor,这个可能在我们 Debug 的时候有点用处,但是我不准备上来就写代码,不妨先来看看 GRPC 的文档,看下有什么好说的,我就挑 Server 端的 Unary 来看吧:

可以看到,在 GRPC 的定义中,这里所谓的 Interceptor 其实就是一个函数,那么这个函数是怎么用的呢?我们找一个用过的例子来看,就找之前 Server 端验证 JWT 的 Interceptor 吧,打开一看:

好,原来这里新建的 Interceptor 就是返回了一个函数,然后在函数内部进行判断,如果正常了,那么就调用业务处理函数,否则,那么就直接返回错误了。

那么这里我们就可以仿照着写一个:

写完之后,在自己的 Server 中试用一下,看看效果怎么样:

然后运行一下,我这里看到的出是:

看样子是正常运行啦,而且客户端也是正常响应的。但是,当我和前面介绍过的 Interceptor 进行集成的时候,问题就出现了,如何同时试用多个 Interceptor 呢,因为从我们的 Interceptor 的实现来看,明显这就是只能存在一个 Interceptor 的情况。

多个 Interceptor

这个时候,我们来回顾一下之前是否有过多个 Interceptor 的情况,回顾了一圈,没有发现,所以这个时候还是应该回到之前使用过的 Repo 中查看一下,看他们是如何解决这个问题的,当我打开 Grpc-ecosystem 的 Repo 的时候,一切都这么自然,人家就放在 README 里面:

这里它将所有的 Interceptor 封装成了一个 Chain,所以我还需要看下 Chain 是怎么实现的,顺便看看我现在的实现能不能满足它的要求:

这么一看,我去,原来 Chain 是这么玩的,那这么一看就知道了,我们写的这个 Interceptor 不用做任何就可以直接使用了,并且,我们也可以看到,Chain 的执行顺序是根据注册顺序,从上到下注册的。

OK,本文就是关于 Interceptor 的介绍了,虽然只是介绍了 Server 端的实现,但是,对于 Client 端来说也是一样的,可以参考用过的一些实现来编写,这些都是很简单的啦,不过就是需要注意到一些业务上的处理,例如重试 Interceptor 中的是否幂等这些。