golang源码分析:middleware的执行顺序
golang源码分析:middleware的执行顺序
go-grpc-middleware封装了认证（auth）, 日志（ logging）, 消息（message）, 验证（validation）, 重试（retries） 和监控（retries）等拦截器。如何使用呢？在初始化grpcserver的时候，参数传入即可
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认证
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拦截注册加到服务端
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
func NewServer(opt ...ServerOption) *Server {
chainUnaryServerInterceptors(s)func chainUnaryServerInterceptors(s *Server) {
chainedInt = chainUnaryInterceptors(interceptors)
s.opts.unaryInt = chainedIntfunc 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具体的执行过程是什么样子的呢？我们继续看源码：
func (s *Server) Serve(lis net.Listener) error {
go func() {
s.handleRawConn(lis.Addr().String(), rawConn)go func() {
s.serveStreams(st)
s.handleStream(st, stream, s.traceInfo(st, stream))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
reply, appErr := md.Handler(info.serviceImpl, ctx, df, s.opts.unaryInt)注意它的第三个参数是一个函数，这里完成了最终的grpc调用。
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
func RegisterHealthServer(s grpc.ServiceRegistrar, srv HealthServer) {
s.RegisterService(&Health_ServiceDesc, srv)
}在Health_ServiceDesc这个元文件中定义了Handler
var Health_ServiceDesc = grpc.ServiceDesc{
Methods: []grpc.MethodDesc{
{
MethodName: "Check",
Handler: _Health_Check_Handler,
},
},type MethodDesc struct {
MethodName string
Handler methodHandler
}可以看到，它其实是触发调用middleware的地方，它把handler当作参数传递给middleware 也就是interceptor，然后就按照我们最初的注册顺序依次执行了。
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 方法本身
type UnaryServerInterceptor func(ctx context.Context, req interface{}, info *UnaryServerInfo, handler UnaryHandler) (resp interface{}, err error)其实我们可以在自定义的 UnaryServerInterceptor方法里面决定handler的执行顺序，从而实现某些操作的顺序的灵活控制，但是一些相互依赖的middleware之间的顺序显得就非常重要了，这个需要我们注册的时候格外小心。
本文分享自 golang算法架构leetcode技术php 微信公众号，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ，欢迎热爱写作的你一起参与！
腾讯云开发者
