nginx反向代理性能(nginx作grpc的反向代理踩坑总结)
nginx反向代理性能
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反向代理内容请搜索开心学习网以前的文章或继续浏览下面的相关文章希望大家以后多多支持开心学习网!
- docker nginx 配置详解(Docker 如何安装 Nginx)
- 实战部署nginxdocker(基于Docker、Nginx和Jenkins实现前端自动化部署)
- nginx 怎么搭建web服务器(Linux+Nginx+Php架设高性能WEB服务器)
- nginx安全配置提示(wdcp Linux面板nginx启用gzip后js未压缩解决方案)
- nginx 配置强制跳转https(Nginx实现https网站配置代码实例)
- nginx反向代理端口号(nginx 代理80端口转443端口的实现)
- nginx 重置端口号(详解如何修改nginx的默认端口)
- nginx和apache服务器配置(Apache、Nginx 服务配置服务器端包含SSI)
- nginxpython编写模块(Python开发之Nginx+uWSGI+virtualenv多项目部署教程)
- 如何设置nginx使用ip访问(nginx基于域名,端口,不同IP的虚拟主机设置的实现)
- nginx安全设置(Nginx+ModSecurity安全模块部署的实现)
- nginx配置ip端口访问(Nginx配置80端口访问8080及项目名地址方法解析)
- 修改宝塔nginx端口(解决宝塔面板nginx/apache防火墙后无法启动)
- 如何提高nginx性能(提升Nginx性能的一些建议)
- nginx中https配置(Nginx配置同一个域名同时支持http与https两种方式访问实现)
- nginx代理docker容器(Docker Nginx容器制作部署实现方法)
- 一课译词 放鸽子(一课译词放鸽子)
- 终于来了,淘宝更改账户名测试中,快去看看你能不能修改(淘宝更改账户名测试中)
- 淘宝支持账号名修改,网友 终于可以 重新做人 了(淘宝支持账号名修改)
- 盘点那些年让人称奇的年终奖 最后一个赢辣条毫无悬念(盘点那些年让人称奇的年终奖)
- 你还没有升职吗 他竟因为几套激励理论,升职了(你还没有升职吗)
- 某知名企业绩效管理体系及薪酬分配体系操作手册(某知名企业绩效管理体系及薪酬分配体系操作手册)
热门推荐
- sqlserver怎么加check约束(浅析SQL Server的分页方式 ISNULL与COALESCE性能比较)
- 常见的几种XSS攻击
- x86与x64的区别?云服务器如何选择操作系统?(x86与x64的区别?云服务器如何选择操作系统?)
- ASP.NET记录错误日志的方式有哪些
- python pandas读取数据库表(Python3.5 Pandas模块之DataFrame用法实例分析)
- 如何用python人脸识别(Python学习笔记之视频人脸检测识别实例教程)
- javascript函数工具有哪些(如何让你的JavaScript函数更加优雅详解)
- 属于web服务器的有哪些(web服务器有几种类型?)
- filezilla搭建ftp服务教程(FileZilla 425 无法连接FTP的解决方法阿里云服务器)
- pandas数据分组使用方法(在Pandas中DataFrame数据合并,连接concat,merge,join的实例)
排行榜
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9