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协议，那有很多实现方法：
通过路径区分
请求将server的信息添加在path里，例如：/server1/service/method，然后nginx转发请求的时候还原为原始的请求：
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的请求，这样就会报404的错误。
通过请求参数区分
也可以将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;
}
}
}
}
但对于gRPC就没这么简单了，首先gRPC不支持URI的写法，nginx转发的请求会保留原来的path，无法在转发的时候修改path，这意味着上述的第一种办法不可行。其次gRPC是基于HTTP 2.0协议的，HTTP2没有queryString这一概念，请求头里有一项:path代表请求的路径，例如/service/method，而这一路径是不能携带请求参数的，也就是:path不能写为/service/method?server=server1。这意味着上述的第二种方法也不可行。
注意到HTTP2中请求头: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的结果，而是新增了一项请求头，相当于请求header里存在两个:path，可能就是因为这个原因导致服务端报了502的错误。
山穷水尽之际想起gRPC的metadata功能，我们可以在client端将server的信息存储在metadata中，然后在nginx路由时根据metadata中server的信息转发给对应的后端服务，这样就实现了我们的需求。对于go语言，设置metadata需要实现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_ip这一语法引用了我们传递的x-ip这个metadata信息。这一方法验证有效，client可以通过nginx proxy成功访问到server的gRPC服务。
总结
nginx的gRPC模块的文档太少了，官方文档只给出了几个指令的用途，并没有说明metadata这一方法，网上的文档也鲜有涉及，导致花了两三天的时间在排查。将整个过程总结在这里，希望能帮助到遇到同一问题的人。
到此这篇关于nginx作grpc的反向代理踩坑总结的文章就介绍到这了,更多相关nginx grpc反向代理内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
相关文章
本文主要介绍了nginx负载均衡下的webshell上传的实现，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2023-03-03
这篇文章主要介绍了容器中使用nginx搭建支持上传下载的文件服务器,在这需要注意为了让nginx支持文件上传，需要下载并运行带有nginx-upload-module模块的容器，需要的朋友可以参考下2022-05-05
本文主要介绍了nginx http响应限速的具体实现,可以使用limite_rate和limit_rate_after来限制HTTP响应的速度,具有一定的参考价值,感兴趣的可以了解一下2024-05-05
Nginx的socket代理通常指的是Nginx通过stream模块来处理非HTTP的 TCP 流量,本文就来介绍一下Nginx Socket代理的实现方法,具有一定的参考价值,感兴趣的可以了解一下2024-04-04
这篇文章主要介绍了nginx地址重定向的方法,小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧2018-08-08
nginx+php出现No input file specified解决办法
这篇文章主要介绍了nginx+php出现No input file specified解决办法,小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧2019-03-03
这篇文章主要给大家分享了关于Nginx出现403 Forbidden的四种解决方案,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧2023-09-09
在项目开发过程中,总是离不开日志解析的工作,虽然有些时候觉得确实挺繁琐的,但是静下心来会发现有时候也是挺有趣的1件工作。 下面这篇文章主要介绍了使用MongoDB分析Nginx日志的方法,需要的朋友可以参考借鉴，一起来看看吧。2017-01-01
nginx作为web服务器一个重要的功能就是反向代理，关于nginx 反向代理的使用你都了解吗，今天通过本文给大家介绍下nginx反向代理及配置文件的组成部分，感兴趣的朋友一起看看吧2022-02-02
angular6+springboot实现前后分离nginx配置
这篇文章主要介绍了angular6+springboot实现前后分离nginx配置详解，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪2023-06-06
最新评论