[译] Service Mesh 利器：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规范中的包，服务和方法名称派生的。 考虑如下 SayHelloRPC方法：

调用 SayHelloRPC方法需要从 /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。

相关阅读：

微博开源的Motan RPC最新进展：新增跨语言及服务治理支持

Upsync：微博开源基于Nginx容器动态流量管理方案

是的，为了更好的支持微服务，我们从PHP迁移到了Go

从单体应用走向微服务:一次API Gateway升级的启示

本文作者 Owen Garrett 由 Jesse 翻译。转载译文请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式

长按二维码 关注「高可用架构」公众号