NGINX 宣布支持 gRPC，可在下个版本 1.13.10 中使用

#扫描上方二维码进入报名#

近日，NGINX 在其博客宣布，NGINX 已完成对 gRPC 的原生支持，并将在下一个 OSS 版本 1.13.10 中提供使用，如果迫不及待希望尝鲜，可下载snapshot 快照来体验一把，也可以给开发团队反馈意见。

而下一个 NGINX Plus 版本将引入对 gRPC 和 HTTP/2 服务器推送的支持。

有了对 gRPC 的支持，NGINX 可以代理 gRPC TCP 连接，还可以终止、检查和跟踪 gRPC 的方法调用。你可以：

发布 gRPC 服务，然后使用 NGINX 应用 HTTP/2 TLS 加密、速率限制、基于 IP 的访问控制列表和日志记录

通过单个端点发布多个 gRPC 服务，使用 NGINX 检查并跟踪每个内部服务的调用

使用 Round Robin, Least Connections 或其他方法在集群分配调用，对 gRPC 服务集群进行负载均衡

关于 gRPC

gRPC是一种远程过程调用协议，用于客户端和服务器应用程序之间的通信。他具有紧凑（节省空间）和可跨多种语言移植的特点，并且支持请求响应和流式交互。 由于其广泛的语言支持和简单的面向用户的设计，该协议越来越受欢迎，其中包括服务网格实现。

一个简单的基于 gRPC 的应用程序

gRPC 通过 HTTP / 2 传输，无论是明文还是 TLS 加密。 gRPC 调用被实现为具有高效编码主体的 HTTP POST 请求（协议缓冲区是标准编码）。 gRPC 响应使用类似的编码体，并在响应结束时使用 HTTP trailers 发送状态码。

按照设计，gRPC 协议不能通过 HTTP 传输。 gRPC 协议规定使用 HTTP / 2，是为了利用 HTTP / 2 连接的复用和流式传输功能。

使用 NGINX 管理 gRPC 服务

公开简单的 gRPC 服务

首先，我们在客户端和服务器应用程序之间插入 NGINX。 NGINX 为服务器应用程序提供了一个稳定可靠的网关。

NGINX 代理 gRPC 流量

先通过 gRPC 更新部署 NGINX。 如果您想从源代码构建 NGINX，记得包含 http_ssl 和 http_v2 模块：

NGINX 使用 HTTP 服务器监听 gRPC 流量，并使用 grpc_pass 指令代理流量。 为 NGINX 创建以下代理配置，在端口 80 上侦听未加密的 gRPC 流量并将请求转发到端口 50051 上的服务器：

确保 grpc_pass 指令中的地址是正确的。 重新编译客户端以指向 NGINX 的 IP 地址并监听端口。

当您运行修改后的客户端时，您会看到与之前相同的响应，但事务将由 NGINX 终止并转发。 您可以在您配置的访问日志中看到它们：

使用 TLS 加密发布 gRPC 服务

Hello World 快速入门示例使用未加密的 HTTP / 2（明文）进行通信。 这对测试和部署来说非常简单，但它不提供生产部署所需的加密。 你可以使用 NGINX 来添加这个加密层。

NGINX SSL 终止 gRPC 流量

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

修改 gRPC 客户端以使用 TLS，连接到端口 1443，并禁用证书检查 - 使用自签名或不可信证书时必需这么做。 例如，如果您使用 Go 示例，则需要：

将 crypto / tls 和 google.golang.org/grpc/credentials 添加到您的导入列表中

将 grpc.Dial() 调用修改为以下内容：

这就是使用 NGINX 来确保 gRPC 流量所需要做的。 在生产部署中，您需要将自签名证书替换为受信任的证书颁发机构（CA）颁发的证书。 客户端将被配置为信任该 CA。

代理加密的 gRPC 服务

您可能还想要在内部加密 gRPC 流量。 您首先需要修改服务器应用程序以侦听 TLS 加密（grpcs）而不是未加密（grpc）连接：

在 NGINX 配置中，您需要更改用于将 gRPC 流量代理到上游服务器的协议：

路由 gRPC 流量

如果您有多个 gRPC 服务，每个服务都由不同的服务器应用程序实现，你可以做什么？ 如果您可以通过单个 TLS 加密的端点发布所有这些服务，岂不是很棒？

NGINX 路由和 SSL 终止 gRPC 流量

使用 NGINX，您可以识别服务和方法，然后使用位置指令路由流量。 您可能已经推断出每个 gRPC 请求的 URL 是从 proto 规范中的包，服务和方法名称派生的。 考虑这个示例 SayHello RPC 方法：

调用 SayHello RPC 方法为 /helloworld.Greeter/SayHello 发出 POST 请求，如以下日志条目所示：

192.168.20.1 - - [01/Mar/2018:13:35:02 +0000] "POST /helloworld.Greeter/SayHello HTTP/2.0" 200 18 "-" "grpc-go/1.11.0-dev"

使用 NGINX 路由流量非常简单：

你可以自己尝试一下。 我们扩展了示例 Hello World 包（在 helloworld.proto 中）以添加一个名为 Dispatcher 的新服务，然后创建了一个实现 Dispatcher 方法的新服务器应用程序。 客户端使用单个 HTTP / 2 连接为 Greeter 和 Dispatcher 服务发出 RPC 调用。 NGINX 将呼叫分开并路由到合适的 gRPC 服务器。

请注意“catch‑all” / location 块。 该块处理与已知 gRPC 调用不匹配的请求。 您可以使用像这样的位置块从相同的 TLS 加密端点提供 Web 内容和其他非 gRPC 服务。

负载平衡 gRPC 呼叫

您现在如何扩展 gRPC 服务以增加容量并提供高可用性？ NGINX 的上游团队是这样做的：

当然，如果您的上游正在侦听 TLS，则可以使用 grpc_pass grpcs：// upstreams。

NGINX 可以采用一系列负载平衡算法来分配上游 gRPC 服务器上的 gRPC 呼叫。NGINX 的内置运行状况检查将检测服务器是否无法响应或产生错误，然后使服务器停止运转。 如果没有服务器可用，则 / error502grpc 位置将返回符合 gRPC 的错误消息。

https://www.nginx.com/blog/nginx-1-13-10-grpc/

有任何问题欢迎留言探讨，或通过以上链接进行反馈。