本文记录应用nginx作gRPC的反向代理踩的坑和解决办法。

背景

家喻户晓，nginx是一款高性能的web服务器，罕用于负载平衡和反向代理。所谓的反向代理是和正向代理绝对应，正向代理即咱们惯例意义上了解的“代理”：例如失常状况下在国内是无法访问google的，如果咱们须要拜访，就须要通过一层代理去转发。这个正向代理代理的是服务端（也就是google），而反向代理则相同，代理的是客户端（也就是用户），用户的申请达到nginx后，nginx会代理用户的申请向理论的后端服务发动申请，并将后果返回给用户。

（图片来自维基百科）

正向代理和反向代理实际上是站在用户的角度来定义的，正向也就是代理用户所要申请的服务，而反向则是代理用户向服务发动申请。两者一个很重要的区别：

正向代理服务方不感知申请方，反向代理申请方不感知服务方。

思考一下下面的例子，你通过代理拜访google时，google只能感知到申请来自代理服务器，而无奈间接感知到你（当然通过cookie等伎俩也能够追踪到）；而通过nginx反向代理时，你是不感知申请具体被转发到哪个后端服务器上的。

nginx最常被用于反向代理的场景就是咱们所熟知的http协定，通过配置nginx.conf文件能够很简略地定义一个反向代理规定：

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    server {
        listen       80;
        server_name  localhost;

        
        location / {
            proxy_pass http://domain;
        }
    }
}

nginx从1.13.10当前就反对gRPC协定的反向代理，配置相似：

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    server {
        listen       81 http2;
        server_name  localhost;

        
        location / {
            grpc_pass http://ip;
        }
    }
}

然而当需要场景更加简单的时候，就发现nginx的gRPC模块实际上有很多坑，实现的能力不如http残缺，当套用http的解决方案时就会呈现问题

场景

最开始咱们的场景很简略，通过gRPC协定实现一个简略的C/S架构：

但这种单纯的直连有些场景下是不可行的，例如client和server在两个网络环境下，彼此不相连通，那就无奈通过简略的gRPC连贯拜访服务。一种解决办法是通过两头的代理服务器转发，用下面说的nginx反向代理gRPC办法：

nginx proxy部署在两个环境都能拜访的集群上，这样就实现了跨网络环境的gRPC拜访。随之而来的问题是如何配置这个路由规定？留神咱们最开始的gRPC的指标节点都是清晰的，也就是server1和server2的ip地址，当两头加了一层nginx proxy后，client发动的gRPC申请的对象都是nginx proxy的ip地址。那client与nginx建设连贯后，nginx如何晓得须要将申请转发给server1还是server2呢？（这里server1和server2不是简略的同一个服务的冗备部署，可能须要依据申请的属性决定由谁响应，例如用户id等，因而不能应用负载平衡随机筛选一个响应申请）

解决办法

如果是http协定，那有很多实现办法：

  • 通过门路辨别
/server1/service/method
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    server {
        listen       80;
        server_name  localhost;

        location ~ ^/server1/ {
            proxy_pass http://domain1/;
        }
        
        location ~ ^/server2/ {
            proxy_pass http://domain2/;
        }
    }
}
http://domain//server1/service/method/service/method
  • 通过申请参数辨别

也能够将server1的信息放在申请参数里：

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    server {
        listen       80;
        server_name  localhost;

        location /service/method {
            if ($query_string ~ x_server=(.*)) {
                proxy_pass http://$1;
            }
        }
    }
}
:path/service/method:path/service/method?server=server1
:path:path
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    server {
        listen       80 http2;
        server_name  localhost;

        location ~ ^/(.*)/service/.* {
            grpc_set_header :path /service/$2;
            grpc_pass http://$1;
        }
    }
}
:path
rpc error: code = Unavailable desc = Bad Gateway: HTTP status code 502; transport: received the unexpected content-type "text/html"
grpc_set_header:path:path
PerRPCCredentials
type extraMetadata struct {
    Ip string
}

func (c extraMetadata) GetRequestMetadata(ctx context.Context, uri ...string) (map[string]string, error) {
    return map[string]string{
        "x-ip": c.Ip,
    }, nil
}

func (c extraMetadata) RequireTransportSecurity() bool {
    return false
}

func main(){
    ...
    // nginxProxy是nginx proxy的ip或域名地址
    var nginxProxy string
    // serverIp是依据申请属性计算好的后端服务的ip
    var serverIp string
    con, err := grpc.Dial(nginxProxy, grpc.WithInsecure(),
        grpc.WithPerRPCCredentials(extraMetadata{Ip: serverIp}))
}

而后在nginx配置里依据这个metadata转发到对应的server：

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    server {
        listen       80 http2;
        server_name  localhost;

        location ~ ^/service/.* {
            grpc_pass grpc://$http_x_ip:8200;
        }
    }
}
$http_x_ipx-ip
总结

nginx的gRPC模块的文档太少了，官网文档只给出了几个指令的用处，并没有阐明metadata这一办法，网上的文档也鲜有波及，导致花了两三天的工夫在排查。将整个过程总结在这里，心愿能帮忙到遇到同一问题的人。