NGINX将支持gRPC

摘要:gRPC已经是新一代微服务的标准RPC框架。对于实现来说,虽然可以用服务框架等手段来做到负载均衡,业界还没有针对gRPC的反向代理软件。NGINIX作为老牌负载均衡软件对gRPC进行了支持。本文作者简要介绍了NGINX这一特性。

NGINX将在1.13.10版本中包含grpc相关功能。

这个版本支持NGINX代理gRPC TCP连接。可以用来:

  • 发布gRPC服务,包括未加密/加密的gRPC服务。

  • 通过单个endpoint发布多个gRPC服务,使用NGINX路由到后端服务。 甚至可以和其他HTTP/2服务使用相同的endpoint,例如网站和 REST API。

  • 反向代理gRPC服务,对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。

使用NGINX管理gRPC服务


下面是一个简单的gRPC程序作为DEMO。

简单gRPC服务

首先,我们在客户端和服务器应用程序之间插入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。 如果你想同时处理两个协议版本,你应该为每个协议版本创建一个监听端口。

发布TLS加密的gRPC服务


上面的示例使用未加密的HTTP/2(明文)进行通信。 这对测试和部署来说非常简单,但生产环境需要加密。 你可以使用NGINX来添加这个加密层。

首先创建一个自签名证书对并修改您的NGINX服务器配置,如下所示:

修改gRPC客户端以使用TLS,连接到端口1443,并禁用证书检查(使用自签名或不可信证书时需要如此)。 如果你使用的是Go,则需要将crypto/tls和google.golang.org/grpc/credentials添加到导入列表中,并将grpc.Dial()调用修改为以下内容:

这就是需要做的所有工作。 在生产环境中,你还需要将自签名证书替换为受信任的证书颁发机构(CA)颁发的证书。

反向代理加密的gRPC服务


如果想在内部调用对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连接向GreeterDispatcher服务发出RPC请求。 NGINX会将请求路由到合适的gRPC服务器。


请注意/ location块。 该块处理与已知gRPC调用不匹配的请求。 您可以使用像这样的location块提供网页内容和其他非gRPC服务。

负载均衡


如何扩展gRPC服务以增加容量并提供高可用性? NGINX的upstream group就是做这事的:

当然,如果您的upstream正在监听TLS,则可以使用grpc_pass grpcs://upstreams 。


NGINX可以采用一系列负载均衡算法来分配后端gRPC服务器上的gRPC请求。 NGINX的内置状况检查将检测后端服务是否无法响应或者是否产生错误,如果检测到后端服务出问题,NGINX会自动移除该节点。 如果没有后端节点可用,则会返回/error502grpc。


你可能感兴趣的:(Nginx)