NGINX将在1.13.10版本中包含grpc相关功能。
这个版本支持NGINX代理gRPC TCP连接。可以用来:
发布gRPC服务,包括未加密/加密的gRPC服务。
通过单个endpoint发布多个gRPC服务,使用NGINX路由到后端服务。 甚至可以和其他HTTP/2服务使用相同的endpoint,例如网站和 REST API。
反向代理gRPC服务,对gRPC服务集群进行负载均衡。
gRPC是一种rpc协议,用于客户端和服务端之间的通信。 gRPC设计的很紧凑并且多语言支持良好,同时支持request/response模式和流式交互。 由于其广泛的语言支持和简单面向用户的设计,该协议越来越受欢迎,其中包含服务混搭(service mesh)实现 。
无论是明文还是TLS加密,gRPC都通过HTTP/2传输。 gRPC request使用HTTP POST请求。 gRPC response也使用类似的方式,并在response结束时使用HTTP trailer 发送状态码。
因为gRPC使用了HTTP/2的连接复用和流式传输功能,所以gRPC不能使用HTTP 1.x。
下面是一个简单的gRPC程序作为DEMO。
首先,我们在客户端和服务器应用程序之间插入NGINX。 NGINX为服务器应用程序提供了一个稳定可靠的网关。
注意这里需要使用带gRPC功能的NGINX。 如果您想从源代码构建NGINX,请记住包含http_ssl和http_v2模块:
NGINX监听gRPC流量,并使用grpc_pass指令代理流量。 下面的配置是将端口80上加密的gRPC流量转发到端口50051上的服务:
我们需要确保grpc_pass指令中的地址是正确的。 重新编译客户端以指向NGINX的IP地址和监听端口。
当运行修改后的客户端时,会看到与之前相同的响应,但请求是经由GINX转发。 我们可以在访问日志中看到请求记录:
注意: NGINX不支持在明文(非TLS)端口上同时支持HTTP/1和HTTP/2。 如果你想同时处理两个协议版本,你应该为每个协议版本创建一个监听端口。
上面的示例使用未加密的HTTP/2(明文)进行通信。 这对测试和部署来说非常简单,但生产环境需要加密。 你可以使用NGINX来添加这个加密层。
首先创建一个自签名证书对并修改您的NGINX服务器配置,如下所示:
修改gRPC客户端以使用TLS,连接到端口1443,并禁用证书检查(使用自签名或不可信证书时需要如此)。 如果你使用的是Go,则需要将crypto/tls和google.golang.org/grpc/credentials添加到导入列表中,并将grpc.Dial()调用修改为以下内容:
这就是需要做的所有工作。 在生产环境中,你还需要将自签名证书替换为受信任的证书颁发机构(CA)颁发的证书。
如果想在内部调用对gRPC请求加密。 首先需要修改服务器应用程序以侦听TLS加密( grpcs)连接:
在NGINX配置中,您需要修改将gRPC流量代理到upstream server的协议:
这里将会介绍如何使用NGINX代理多个gRPC后端服务。
使用NGINX,您可以识别服务和方法,然后使用location指令路由流量。 您可能已经猜出gRPC请求URL是从proto规范中的包,服务和方法名称派生的。 考虑如下SayHello RPC方法:
调用SayHello RPC方法需要从/helloworld.Greeter/SayHello发出POST请求,如以下日志条目所示:
使用NGINX路由请求非常简单:
你可以自己尝试一下。 例子中扩展了Hello World包(在helloworld.proto )添加一个名为Dispatcher的新服务,然后创建了一个实现Dispatcher方法的新服务。 客户端使用一个HTTP/2连接向Greeter和Dispatcher服务发出RPC请求。 NGINX会将请求路由到合适的gRPC服务器。
请注意/ location块。 该块处理与已知gRPC调用不匹配的请求。 您可以使用像这样的location块提供网页内容和其他非gRPC服务。
如何扩展gRPC服务以增加容量并提供高可用性? NGINX的upstream group就是做这事的:
当然,如果您的upstream正在监听TLS,则可以使用grpc_pass grpcs://upstreams 。
NGINX可以采用一系列负载均衡算法来分配后端gRPC服务器上的gRPC请求。 NGINX的内置状况检查将检测后端服务是否无法响应或者是否产生错误,如果检测到后端服务出问题,NGINX会自动移除该节点。 如果没有后端节点可用,则会返回/error502grpc。