上一个小节中讲到了关于拦截器简单的使用，查看官网文档的时候，其实也有讲到关于拦截器的一些说明。这里再补充一下

第三方库封装思路拆解

从官网的文档里，顺腾摸瓜的拆解一下我们的第三方拦截库的一些思路。

1：grpc.ServerInterceptor官网参数说明

官网关于拦截器grpc.ServerInterceptor使用到的RpcMethodHandler自介绍，深入到第三方库的时候其实里面处理返回也是一个RpcMethodHandler

拦截器intercept_service官方的说明：

作用：在业务执行之前拦截传入的RPC
具体的需要用的额参数有：
- continuation 使用HandlerCallDetails并继续调用链中的下一个拦截器(如果有的话)或RPC处理程序查找逻辑的函数，调用详细信息作为参数传递，如果RPC被认为是服务的，则返回RpcMethodHandler实例，否则不会返回RpcMethodHandler实例。---（来自翻译的结果）
- handler_call_details 描述RPC的HandlerCallDetails，对应的是grpc.HandlerCallDetails的类型
上面的意思大概是：需要经过continuation进行包装我们一个handler_call_details才返回一个RpcMethodHandler实例

（上小节也有说到）它是一个RPC请求描述,里面包含有两个属性信息：

它是一个任意多个RPC方法的实现
它需要实现一个抽象方法service，而这个抽象方法需要处理的就是我们的传入的一个RPC请求描述HandlerCallDetails，这里面可以对我们的请求进行相关的类型的判断，它是否符合一个我们的RPC支持的各类类型，如果支持的话，则返回一个RpcMethodHandler来表示它是一个可用的RPC的服务请求，如果不是的话，那只能进行打断处理。

一个服务可以有多个方法名，但只有一个服务名称

它是一个服务的RPC方法请求实现（意思就是没一个RPC请求理解是为是一个个的RpcMethodHandler 对象
对应我们的GRPC的HandlerCallDetails，它是对RPC请求描述所以RpcMethodHandler 里面包含有对应的HandlerCallDetails

它支持的RPC请求类型主要有以下几个（标识这个请求是属于那种类型的RPC请求）

- request_streaming
- response_streaming

- request_deserializer
- response_serializer

- unary_unary
- unary_stream

- stream_unary
- stream_stream

一个服务可以有多个方法名，但只有一个服务名称

结合上面对几个对象的了解，结合我们的第三方的库其实可以看得出来，第三方库其实就是对我们的 grpc.RpcMethodHandler进行的封装。而我们的 grpc.RpcMethodHandler是一个RPC方法的实现。

再梳理一下第三方库实现的流程：

1：定义一个自己的需要实现的抽象类，这个抽象类实现了官网的grpc.ServerInterceptor抽象方法
2：在实现grpc.ServerInterceptor抽象方法intercept_service里面通过
```
next_handler = continuation(handler_call_details)
```
返回一个RpcMethodHandler对象实例。