golang源码分析:middleware的执行顺序

go-grpc-middleware封装了认证（auth）, 日志（ logging）, 消息（message）, 验证（validation）, 重试（retries）和监控（retries）等拦截器。如何使用呢？在初始化grpcserver的时候，参数传入即可

代码语言：javascript复制

import "github.com/grpc-ecosystem/go-grpc-middleware"
myServer := grpc.NewServer(
    grpc.UnaryInterceptor(grpc_middleware.ChainUnaryServer(
        grpc_ctxtags.UnaryServerInterceptor(),
        grpc_opentracing.UnaryServerInterceptor(),
        grpc_prometheus.UnaryServerInterceptor,
        grpc_zap.UnaryServerInterceptor(zapLogger),
        grpc_auth.UnaryServerInterceptor(myAuthFunction),
        grpc_recovery.UnaryServerInterceptor(),
    )),
)

也可以自定义拦截器，比如auth认证

代码语言：javascript复制

func AuthInterceptor() grpc.UnaryServerInterceptor {
    return func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (resp interface{}, err error) {
        md, ok := metadata.FromIncomingContext(ctx)
        if !ok {
            err := grpc.Errorf(codes.Unauthenticated, "无Token认证信息")
            return nil, err
        }
        var (
            appid  string
            appkey string
        )

        if val, ok := md["appid"]; ok {
            appid = val[0]
        }

        if val, ok := md["appkey"]; ok {
            appkey = val[0]
        }

        if appid != "101010" || appkey != "i am key" {
            err := grpc.Errorf(codes.Unauthenticated, "Token认证信息无效: appid=%s, appkey=%s", appid, appkey)
            return nil, err
        }
        return handler(ctx, req)
    }
}

把grpc_auth拦截注册加到服务端

代码语言：javascript复制

Copy
grpcServer := grpc.NewServer(
     grpc.UnaryInterceptor(grpc_middleware.ChainUnaryServer(
	grpc_auth.UnaryServerInterceptor(auth.AuthInterceptor),
	 )),
)

当然我们也可以定义其他的middleware，比如grpc_recovery恢复、grpc_zap日志记录等等。

那么问题来了，这么多middleware的执行顺序是怎么样子的，我们注册middleware的顺序有严格要求吗？作为一个非ctrl c v的程序猿其实应该考虑这些问题的。为了弄清楚这个问题，还是从源码开始入手

google.golang.org/grpc@v1.45.0/server.go

代码语言：javascript复制

    func NewServer(opt ...ServerOption) *Server {
      chainUnaryServerInterceptors(s)

代码语言：javascript复制

func chainUnaryServerInterceptors(s *Server) {
      chainedInt = chainUnaryInterceptors(interceptors)
      s.opts.unaryInt = chainedInt

代码语言：javascript复制

func chainUnaryInterceptors(interceptors []UnaryServerInterceptor) UnaryServerInterceptor {
  return func(ctx context.Context, req interface{}, info *UnaryServerInfo, handler UnaryHandler) (interface{}, error) {
      state.next = func(ctx context.Context, req interface{}) (interface{}, error) {
      if state.i == len(interceptors)-1 {
        return interceptors[state.i](ctx, req, info, handler)
      }
      state.i  
      return interceptors[state.i-1](ctx, req, info, state.next)
    }
    return state.next(ctx, req)

可以看到，它是以我们注册的顺序，把所有的middleware串联起来，依次执行，然后以函数的形式返回回来，赋值到s.opts.unaryInt ，所以可以确定grpc middleware执行顺序：按照注册顺序从前往后。

那么问题来了，middleware具体的执行过程是什么样子的呢？我们继续看源码：

代码语言：javascript复制

func (s *Server) Serve(lis net.Listener) error {
    go func() {
      s.handleRawConn(lis.Addr().String(), rawConn)

代码语言：javascript复制

go func() {
    s.serveStreams(st)
        s.handleStream(st, stream, s.traceInfo(st, stream))

代码语言：javascript复制

func (s *Server) handleStream(t transport.ServerTransport, stream *transport.Stream, trInfo *traceInfo) {
    if md, ok := srv.methods[method]; ok {
      s.processUnaryRPC(t, stream, srv, md, trInfo)
      return

函数调用的时候它从注册的函数里面选取一个然后进行调用，注册的过程可以参考golang源码分析：grpc 服务注册，processUnaryRPC函数内部调用了md.Handler

代码语言：javascript复制

reply, appErr := md.Handler(info.serviceImpl, ctx, df, s.opts.unaryInt)

注意它的第三个参数是一个函数，这里完成了最终的grpc调用。

代码语言：javascript复制

        df := func(v interface{}) error {
          if err := s.getCodec(stream.ContentSubtype()).Unmarshal(d, v); 
             sh.HandleRPC(stream.Context(), &stats.InPayload{
              RecvTime:   time.Now(),
              Payload:    v,
              WireLength: payInfo.wireLength   headerLen,
              Data:       d,
              Length:     len(d),
            })

可以看到md是通过元数据从全局的map里面取出来的，Handler其实是生成的代码。它的最后一个参数 s.opts.unaryInt 就是我们最初注册middleware链。还是以健康检查的源码为例，看下Handler的调用过程：

google.golang.org/grpc@v1.45.0/health/grpc_health_v1/health_grpc.pb.go

代码语言：javascript复制

func RegisterHealthServer(s grpc.ServiceRegistrar, srv HealthServer) {
  s.RegisterService(&Health_ServiceDesc, srv)
}

在Health_ServiceDesc这个元文件中定义了Handler

代码语言：javascript复制

var Health_ServiceDesc = grpc.ServiceDesc{
  Methods: []grpc.MethodDesc{
    {
      MethodName: "Check",
      Handler:    _Health_Check_Handler,
    },
  },

代码语言：javascript复制

type MethodDesc struct {
  MethodName string
  Handler    methodHandler
}

可以看到，它其实是触发调用middleware的地方，它把handler当作参数传递给middleware 也就是interceptor，然后就按照我们最初的注册顺序依次执行了。

代码语言：javascript复制

func _Health_Check_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
  handler := func(ctx context.Context, req interface{}) (interface{}, error) {
    return srv.(HealthServer).Check(ctx, req.(*HealthCheckRequest))
  }
  return interceptor(ctx, in, info, handler)

回过头来，我们再看看我们UnaryServerInterceptor的定义，它是一个方法，有四个参数

ctx context.Context：请求上下文
req interface{}：RPC 方法的请求参数
info *UnaryServerInfo：RPC 方法的所有信息
handler UnaryHandler：RPC 方法本身

代码语言：javascript复制

type UnaryServerInterceptor func(ctx context.Context, req interface{}, info *UnaryServerInfo, handler UnaryHandler) (resp interface{}, err error)

其实我们可以在自定义的 UnaryServerInterceptor方法里面决定handler的执行顺序，从而实现某些操作的顺序的灵活控制，但是一些相互依赖的middleware之间的顺序显得就非常重要了，这个需要我们注册的时候格外小心。

rpc go android 网络安全

0 人点赞