关于nginx:将-NGINX-部署为-API-网关第-3-部分发布-gRPC-服务

原文作者：Liam Crilly of F5

原文链接：将 NGINX 部署为 API 网关，第 3 局部：公布 gRPC 服务

转载起源：NGINX 官方网站

本文是“将 NGINX 开源版和 NGINX Plus 部署为 API 网关”系列博文的第三篇。

第 1 局部具体阐明了 NGINX 开源版和 NGINX Plus 作为基于 HTTP 的 RESTful API 的 API 网关的一些用例。
第 2 局部对这些用例进行了扩大，探讨了一系列可用于爱护生产环境中后端 API 服务的安全措施。
本文解释了如何将 NGINX 开源版和 NGINX Plus 部署为 gRPC 服务的 API 网关。文章最后公布于 2018 年，随着 NGINX Plus Release 23 中引入了对原生 gRPC 健康检查协定的反对，特此更新，以不便大家充分利用 NGINX 开源版和 NGINX Plus。更新详情请参阅下文“施行健康检查”一节。

注：除非另有阐明，否则本文中的所有信息都实用于 NGINX Plus 和 NGINX 开源版。为了便于浏览，当探讨内容同时实用于两个版本时，下文将它们统称为“NGINX”。

近年来，介绍微服务利用架构的概念和劣势的文章十分多，其中以 NGINX 博文居首。微服务利用的外围是 HTTP API，本系列博文的前两篇文章应用了一个假如的 REST API 来阐明 NGINX 如何解决此类利用。

只管基于 JSON 音讯格局的 REST API 在古代利用中十分风行，但它并不是所有场景或所有企业的现实之选。最常见的挑战是：

文档规范 —— 如果没有良好的开发者制度或强制性的文档要求，最初很容易产生大量不足精确定义的 REST API。Open API 标准已成为 REST API 的通用接口描述语言，但其应用却不是强制性的，须要开发组织外部的无力治理。
事件和长连贯 —— REST API 以及它们应用 HTTP 传输，简直决定了所有 API 调用都是申请 – 响应模式。当客户端利用须要服务器反馈音讯时，应用 HTTP 长轮询和 WebSocket 等解决方案会有所帮忙，但应用此类解决方案最终都须要构建一个独自、相邻的 API。
简单事务 —— REST API 是围绕惟一资源的概念构建的，每个资源都由一个 URI 示意。当利用须要调用多个资源更新时，要么须要多个 API 调用（效率低下），要么必须在后端实现简单的事务（与 REST 的外围准则相悖）。

近年来，gRPC 已倒退成为构建分布式应用，尤其是微服务利用的代替办法。gRPC 最后由 Google 开发，并于 2015 年开源，现已成为云原生计算基金会的一个我的项目。值得注意的是，gRPC 应用 HTTP/2 作为传输机制，并利用其二进制数据格式和多路复用流性能。

gRPC 的次要劣势包含：

紧耦合的接口定义语言（协定缓冲区）
对流数据的原生反对（双向）
高效的二进制数据格式
主动生成多语言的代码，反对真正的多语言开发环境，且不会产生互操作性问题

本系列博文的前两篇形容了如何通过单个入口点（例如 https://api.example.com）交付多个 API。当 NGINX 部署为 gRPC 网关时，gRPC 流量的默认行为和特色促使 NGINX 也要采纳这种办法。尽管 NGINX 能够在同一主机名和端口上共享 HTTP 和 gRPC 流量，但最好还是将它们离开，次要有以下起因有：

REST 和 gRPC 利用的 API 客户端须要不同格局的谬误响应
REST 和 gRPC 拜访日志的相干字段有所不同
因为 gRPC 不波及旧版 Web 浏览器，因而它能够施行更严格的 TLS 策略

为了实现这种拆散，咱们须要批改 gRPC 网关主配置文件 grpc_gateway.conf 的 server{} 模块，它位于 /etc/nginx/conf.d 目录。

log\_format grpc\_json escape=json '{"timestamp":"$time_iso8601",'
           '"client":"$remote_addr","uri":"$uri","http-status":$status,''"grpc-status":$grpc\_status,"upstream":"$upstream\_addr"''"rx-bytes":$request\_length,"tx-bytes":$bytes\_sent}';

map $upstream\_trailer\_grpc\_status $grpc\_status {
    default $upstream\_trailer\_grpc_status; # grpc-status is usually a trailer
    ''      $sent\_http\_grpc_status; # Else use the header, whatever its source
}

server {
    listen 50051 http2; # In production, comment out to disable plaintext port
    listen 443   http2 ssl;
    server_name  grpc.example.com;
    access\_log   /var/log/nginx/grpc\_log.json grpc_json;

    # TLS config
    ssl_certificate      /etc/ssl/certs/grpc.example.com.crt;
    ssl\_certificate\_key  /etc/ssl/private/grpc.example.com.key;
    ssl\_session\_cache    shared:SSL:10m;
    ssl\_session\_timeout  5m;
    ssl_ciphers          HIGH:!aNULL:!MD5;
    ssl_protocols        TLSv1.2 TLSv1.3;

咱们首先定义 gRPC 流量拜访日志中的条目格局（第 1-4 行）。在本例中，咱们应用 JSON 格局从每个申请中捕捉最相干的数据。请留神，HTTP method 不包含在内，因为所有 gRPC 申请都应用 POST。咱们还记录了 gRPC 状态代码和 HTTP 状态代码。然而，gRPC 状态代码可通过不同的形式生成。在失常状况下，grpc-status 从后端返回 HTTP/2 音讯头，但在一些谬误状况下，它可能会被后端或 NGINX 本人返回 HTTP/2 音讯头。为了简化拜访日志，咱们应用 map 块（第 6-9 行）来评估新变量 $grpc_status 并从产生该变量的中央获取 gRPC 状态。

此配置蕴含两个 监听 指令（第 12 行和第 13 行），所以咱们能够测试明文（端口 50051）和受 TLS 爱护的（端口 443）流量。http2 参数将 NGINX 配置为承受 HTTP/2 连贯 —— 请留神，这与 ssl 参数无关。另请留神，端口 50051 是 gRPC 的惯例明文端口，但不举荐在生产环境中应用。

TLS 配置是惯例配置，但 ssl_protocols 指令（第 23 行）除外，该指令将 TLS 1.2 指定为最弱的可承受协定。HTTP/2 标准要求应用 TLS 1.2（或更高版本），以保障所有客户端都反对对 TLS 的 SNI (Server Name Indication) 扩大。这意味着 gRPC 网关能够与其余 server{} 模块中定义的虚构服务器共享端口 443。

为理解 NGINX 的 gRPC 性能，咱们应用了一个简略的测试环境，该环境代表了 gRPC 网关的要害组件，并部署了多个 gRPC 服务。咱们应用官网 gRPC 指南中的两个示例利用：helloworld（用 Go 编写）和 RouteGuide（用 Python 编写）。RouteGuide 利用特地有用，因为它蕴含了四种 gRPC 服务办法：

简略 RPC（繁多申请 – 响应）
响应流 RPC
申请流 RPC
双向流 RPC

所有 gRPC 服务都作为 Docker 容器装置在咱们的 NGINX 主机上。无关构建该测试环境的残缺阐明，请参阅附录。

NGINX 作为 gRPC 网关的测试环境

咱们配置 NGINX 以理解 RouteGuide 和 helloworld service，以及可用容器的地址。

upstream routeguide_service {
    zone routeguide_service 64k;
    server 127.0.0.1:10001;
    server 127.0.0.1:10002;
    server 127.0.0.1:10003;
}

upstream helloworld_service {
    zone helloworld_service 64k;
    server 127.0.0.1:20001;
    server 127.0.0.1:20002;
}

咱们为每个 gRPC 服务增加一个 upstream 模块（第 40-45 和 47-51 行），并应用运行 gRPC 服务器代码的各个容器的地址填充它们。

通过 NGINX 监听 gRPC 的惯例明文端口 (50051)，咱们将路由信息增加到配置中，以便客户端申请可能达到正确的后端 service。但首先咱们须要理解 gRPC method 调用如何示意为 HTTP/2 申请。下图为 RouteGuide service 的 route_guide.proto 文件的缩略版，阐明了 package、service 和 RPC method 如何造成 URI，如 NGINX 所见。

协定缓冲区 RPC method 如何转换为 HTTP/2 申请

因而，HTTP/2 申请中携带的信息只需匹配包名（此处为 routeguide 或 helloworld）即可用于路由。

# Routing
    location /routeguide. {grpc_pass grpc://routeguide_service;}
    location /helloworld. {grpc_pass grpc://helloworld_service;}

第一个 location 模块（第 26 行），不蕴含任何修饰符，定义了一个前缀匹配，以便 /routeguide. 匹配该包对应的 .proto 文件中定义的所有 service 和 RPC method。因而，grpc_pass 指令（第 27 行）将来自 RouteGuide 客户端的所有申请传递给上游 grouprouteguide_service。该配置（以及第 29 行和第 30 行的 helloworld 服务的并行配置）提供了 gRPC 包与其后端 service 之间的简略映射。

请留神，grpc_pass 指令的参数以 grpc:// 形式申请，该申请形式应用明文 gRPC 连贯代理申请。如果后端配置了 TLS，咱们能够应用 grpcs:// 通过端到端加密来爱护 gRPC 连贯。

运行 RouteGuide 客户端后，咱们能够通过查看日志文件来确认路由行为。此处，咱们看到 RouteChat RPC method 被路由到在端口 10002 上运行的容器。

$ python route_guide_client.py
...
$ tail -1 /var/log/nginx/grpc_log.json | jq
{
  "timestamp": "2021-01-20T12:17:56+01:00",
  "client": "127.0.0.1",
  "uri": "/routeguide.RouteGuide/RouteChat",
  "http-status": 200,
  "grpc-status": 0,
  "upstream": "127.0.0.1:10002",
  "rx-bytes": 161,
  "tx-bytes": 212
}

如上所示，将多个 gRPC 服务简略、高效的路由到不同后端，只须要多数几行配置。然而，生产环境中的路由要求可能更加简单，须要基于 URI 中的其余元素（gRPC 服务甚至单个 RPC method）进行路由。

以下配置片段扩大了后面的示例，以便将双向流式 RPC methodRouteChat 路由到同一个后端，而将其余所有 RouteGuide 办法路由到不同的后端。

# Service-level routing
location /routeguide.RouteGuide/ {grpc_pass grpc://routeguide_service_default;}

# Method-level routing
location = /routeguide.RouteGuide/RouteChat {grpc_pass grpc://routeguide_service_streaming;}

第二个 location 指令（第 7 行）应用“=”（等号）来示意这是 RouteChatRPC method 的 URI 上的准确匹配。准确匹配在前缀匹配之前进行解决，这意味着 RouteChatURI 不会思考其余 location 块。

gRPC 谬误与传统 HTTP 流量的谬误有些不同。客户端冀望谬误条件示意为 gRPC 响应，这使得当 NGINX 配置为 gRPC 网关时，默认的 NGINX 谬误页面集（HTML 格局）将不适宜应用。咱们的解决办法是为 gRPC 客户端指定一组自定义的谬误响应。

# Error responses
    include conf.d/errors.grpc_conf; # gRPC-compliant error responses
    default_type application/grpc;   # Ensure gRPC for all error responses

残缺的 gRPC 谬误响应集是一个绝对较长且大部分是动态响应的配置，因而咱们将它们保留在一个独自的文件 errors.grpc_conf 中，并应用 include 指令（第 34 行）援用它们。与 HTTP/REST 客户端不同，gRPC 客户端利用不须要解决大量的 HTTP 状态代码。gRPC 文档指定了 NGINX 等两头代理必须如何将 HTTP 错误代码转换为 gRPC 状态代码，以便客户端始终可能接管到适合的响应。咱们应用 error_page 指令来执行这个映射。

# Standard HTTP-to-gRPC status code mappings
# Ref: https://github.com/grpc/grpc/blob/master/doc/http-grpc-status-mapping.md
#
error_page 400 = @grpc_internal;
error_page 401 = @grpc_unauthenticated;
error_page 403 = @grpc_permission_denied;
error_page 404 = @grpc_unimplemented;
error_page 429 = @grpc_unavailable;
error_page 502 = @grpc_unavailable;
error_page 503 = @grpc_unavailable;
error_page 504 = @grpc_unavailable;

每个规范 HTTP 状态代码都应用 @ 前缀传递到指定 location，这样就能够生成合乎 gRPC 要求的响应。例如，HTTP 404 响应在外部被重定向到 @grpc_unimplementedlocation，该 location 文件定义如下：

location @grpc_unimplemented {
    add_header grpc-status 12;
    add_header grpc-message unimplemented;
    return 204;
}

@grpc_unimplemented 命名 location 仅可用于外部 NGINX 解决 —— 因为没有可路由的 URI，客户端无奈间接申请该 location。在 location 中，咱们填充强制性 gRPC 标头并应用 HTTP 状态代码 204(No Content) 发送它们（不蕴含响应注释），从而结构 gRPC 响应。

咱们能够应用 curl(1) 命令模仿一个行为不端的 gRPC 客户端去申请一个不存在的 gRPC method。然而请留神，因为协定缓冲区应用二进制数据格式，curl 通常不适宜作为 gRPC 测试客户端。要在命令行上测试 gRPC，可思考应用 grpc_cli。

$ curl -i --http2 -H "Content-Type: application/grpc" -H "TE: trailers" -X POST https://grpc.example.com/does.Not/Exist
HTTP/2 204 
server: nginx/1.19.5
date: Wed, 20 Jan 2021 15:03:41 GMT
grpc-status: 12
grpc-message: unimplemented

下面援用的 grpc_errors.conf 文件还蕴含 NGINX 可能生成的其余谬误响应的 HTTP 到 gRPC 状态代码映射，例如超时和客户端证书谬误。

gRPC 元数据容许客户端在 RPC method 调用的同时发送附加信息，而无需将这些数据作为协定缓冲区标准文件（.proto 文件）的一部分。元数据是一个简略的键值对（key-value）列表，每个键值对都作为独自的 HTTP/2 标头传输。因而，NGINX 拜访元数据非常容易。

在元数据的泛滥用例中，客户端身份验证对 gRPC API 网关来说是最常见的。以下配置片段显示了 NGINX Plus 如何应用 gRPC 元数据执行 JWT 身份验证（JWT 身份验证是 NGINX Plus 的独有性能）。在此示例中，JWT 在 auth-token 元数据中发送。

location /routeguide. {
    auth_jwt realm=routeguide token=$http_auth_token;
    auth_jwt_key_file my_idp.jwk;
    grpc_pass grpc://routeguide_service;
}

对 NGINX Plus 来说，每个 HTTP 申请标头都可作为一个名为 $http__header_ 的变量来应用。标头名称中的连字符 (-) 转换为变量名称中的下划线 (_ )，因而 JWT 可用作 $http_auth_token（第 2 行）。

如果 API 密钥用于身份验证（可能是现有的 HTTP/REST API），那么这些密钥也能够在 gRPC 元数据中携带，并由 NGINX 验证。本博客系列的第 1 局部提供了 API 密钥身份验证的配置。

当对多个后盾服务器进行负载平衡时，肯定要防止将申请发送到已敞开或不可用的后盾服务器。借助 NGINX Plus，咱们能够应用被动健康检查被动向后盾服务器发送带外申请，并在它们未按预期响应健康检查时将其从负载平衡轮换中移除。通过这种形式，咱们能够确保客户端申请永远不会被传输到进行服务的后盾服务器。

以下配置片段为 RouteGuide 和 helloworld gRPCservice 启用了被动健康检查；为了突出显示相干配置，该片段省略了一些指令，这些指令蕴含在后面几节中应用的 grpc_gateway.conf 文件中。

server {
    listen 50051 http2; # Plaintext

    # Routing
    location /routeguide. {
        grpc_pass grpc://routeguide_service;
        health_check type=grpc grpc_status=12; # 12=unimplemented
    }
    location /helloworld. {
        grpc_pass grpc://helloworld_service;
        health_check type=grpc grpc_status=12; # 12=unimplemented
    }
}

对于每个路由，咱们当初还指定 health_check 指令（第 17 和 21 行）。正如 type=grpc 参数所指定的，NGINX Plus 应用 gRPC 健康检查协定向上游 group 中的每个服务器发送健康检查。然而，咱们简略的 gRPC 服务没有实现 gRPC 健康检查协定，因而咱们心愿它们应用示意“unimplemented”(grpc_status=12) 的状态代码进行响应。当它们应用这种状态代码进行响应时，就足以表明咱们正在与一个流动的 gRPC 服务进行通信。

有了这个配置，咱们能够敞开任何后端容器，且 gRPC 客户端不会呈现提早或超时。被动健康检查是 NGINX Plus 的独有性能；无关 gRPC 健康检查的更多信息，请浏览咱们的博客。

grpc_gateway.conf 中的示例配置适宜生产环境应用，其中对 TLS 进行了一些小的批改。基于 package、service 或 RPC method 路由 gRPC 申请的能力表明现有的 NGINX 性能能够以 HTTP/REST API 或惯例 Web 流量完全相同的形式利用于 gRPC 流量。在每种状况下，相干的 location 模块都能够通过进一步的配置（例如速率限度或带宽管制）进行扩大。

在对于将 NGINX 开源版和 NGINX Plus 部署为 API 网关系列博文的第三篇也是最初一篇博文中，咱们重点介绍了将 gRPC 作为构建微服务利用的云原生技术。咱们展现了 NGINX 如何可能像交付 HTTP/REST API 一样无效地交付 gRPC 利用，以及如何通过 NGINX 作为多用途 API 网关公布这两种 API。

无关本文应用的测试环境的阐明位于下面的附录中，您能够从咱们的 GitHub Gist 存储库中下载所有文件。

查看本系列博文的其余文章：

第 1 局部解释了如何在一些基于 HTTP 的根本的 API 网关用例中配置 NGINX。
第 2 局部探讨了爱护后端服务免受歹意或不良客户端攻打的更高级用例。

如欲试用作为 API 网关的 NGINX Plus，请立刻下载 30 天收费试用版，或与咱们分割以探讨您的用例。在试用期间，您能够应用位于咱们的 GitHub Gist 存储库的残缺配置文件集。

以下阐明将测试环境装置在一个虚拟机上，不便隔离和重复使用。当然也如果有条件也能够装置在物理服务器上。

为了简化测试环境，咱们应用 Docker 容器来运行 gRPC 服务。这么做的的益处是咱们不须要在测试环境中应用多个主机，但依然能够像在生产环境中一样，让 NGINX 通过网络调用建设代理连贯。

Docker 还反对咱们在不同的端口上运行每个 gRPC 服务的多个实例，而无需批改代码。每个 gRPC 服务监听容器内的端口 50051，该端口映射到虚拟机上惟一的 localhost 端口。这反过来开释了端口 50051，NGINX 能够将其用作监听端口。因而，当测试客户端应用其预配置的端口 50051 连贯时，它们会连贯到 NGINX。

依据 NGINX Plus 管理员指南中的阐明装置 NGINX 开源版或 NGINX Plus。
将以下文件从 GitHub Gist 存储库复制到 /etc/nginx/conf.d :

grpc_gateway.conf
errors.grpc_conf

留神：如果未应用 TLS，则正文掉 grpc_gateway.conf 中的 ssl_* 指令。

3. 启动 NGINX 开源版或 NGINX Plus。

$ sudo nginx

对于 Debian 和 Ubuntu，运行：

$ sudo apt-get install docker.io

对于 CentOS、RHEL 和 Oracle Linux，运行：

$ sudo yum install docker

1. 通过以下 Dockerfile 为 RouteGuide 容器构建 Docker 镜像。

# This Dockerfile runs the RouteGuide server from
# https://grpc.io/docs/tutorials/basic/python.html

FROM python
RUN pip install grpcio-tools 
RUN git clone -b v1.14.x https://github.com/grpc/grpc
WORKDIR grpc/examples/python/route_guide

EXPOSE 50051
CMD ["python", "route_guide_server.py"]

您能够在构建之前将 Dockerfile 复制到本地子目录，也能够将 Dockerfile 的 Gist 的 URL 指定为 dockerbuild 命令的参数：

$ sudo docker build -t routeguide https://gist.githubusercontent.com/nginx-gists/87ed942d4ee9f7e7ebb2ccf757ed90be/raw/ce090f92f3bbcb5a94bbf8ded4d597cd47b43cbe/routeguide.Dockerfile

2. 确认镜像是通过运行 dockerimages 构建的。

$ sudo docker images
REPOSITORY     TAG          IMAGE ID          CREATED         SIZE
routeguide     latest       63058a1cf8ca      1 minute ago    1.31 GB
python         latest       825141134528      9 days ago      923 MB

3. 启动 RouteGuide 容器。

$ sudo docker run --name rg1 -p 10001:50051 -d routeguide
$ sudo docker run --name rg2 -p 10002:50051 -d routeguide
$ sudo docker run --name rg3 -p 10003:50051 -d routeguide

4. 运行 docker ps，查看三个容器是否都已启动。（为了便于浏览，咱们将示例输入拆分成了多行。）

$ sudo docker ps
CONTAINER ID  IMAGE       COMMAND              STATUS        ...
d0cdaaeddf0f  routeguide  "python route_g..."  Up 2 seconds  ...
c04996ca3469  routeguide  "python route_g..."  Up 9 seconds  ...
2170ddb62898  routeguide  "python route_g..."  Up 1 minute   ...

      ... PORTS                     NAMES
      ... 0.0.0.0:10003->50051/tcp  rg3
      ... 0.0.0.0:10002->50051/tcp  rg2
      ... 0.0.0.0:10001->50051/tcp  rg1

输入中的 PORTS 列显示了每个容器如何将不同的本地端口映射到容器内的端口 50051。

1. 通过以下 Dockerfile 为 helloworld 容器构建 Docker 镜像。

# This Dockerfile runs the helloworld server from
# https://grpc.io/docs/quickstart/go.html

FROM golang
RUN go get -u google.golang.org/grpc
WORKDIR $GOPATH/src/google.golang.org/grpc/examples/helloworld

EXPOSE 50051
CMD ["go", "run", "greeter_server/main.go"]

您能够在构建之前将 Dockerfile 复制到本地子目录，也能够将 Dockerfile 的 Gist 的 URL 指定为 dockerbuild 命令的参数：

$ sudo docker build -t helloworld https://gist.githubusercontent.com/nginx-gists/87ed942d4ee9f7e7ebb2ccf757ed90be/raw/ce090f92f3bbcb5a94bbf8ded4d597cd47b43cbe/helloworld.Dockerfil 下载和构建镜像可能须要几分钟工夫。呈现音讯 Successfully built 和一个十六进制字符串（image ID）即示意构建实现。

下载和构建镜像可能须要几分钟工夫。呈现音讯 Successfullybuilt 和一个十六进制字符串（image ID）即示意构建实现。

2. 确认镜像是通过运行 dockerimages 构建的。

$ sudo docker images
REPOSITORY     TAG          IMAGE ID          CREATED           SIZE
helloworld     latest       e5832dc0884a      10 seconds ago    926MB
routeguide     latest       170761fa3f03      4 minutes ago     1.31GB
python         latest       825141134528      9 days ago        923MB
golang         latest       d0e7a411e3da      3 weeks ago       794MB

3. 启动 helloworld 容器。

$ sudo docker run --name hw1 -p 20001:50051 -d helloworld
$ sudo docker run --name hw2 -p 20002:50051 -d helloworld

每个命令执行胜利时，都会呈现一个长的十六进制字符串，代表正在运行的容器。

4. 运行 dockerps，查看两个 helloworld 容器是否都已启动。

$ sudo docker ps
CONTAINER ID  IMAGE       COMMAND              STATUS        ... 
e0d204ae860a  helloworld  "go run greeter..."  Up 5 seconds  ... 
66f21d89be78  helloworld  "go run greeter..."  Up 9 seconds  ... 
d0cdaaeddf0f  routeguide  "python route_g..."  Up 4 minutes  ... 
c04996ca3469  routeguide  "python route_g..."  Up 4 minutes  ... 
2170ddb62898  routeguide  "python route_g..."  Up 5 minutes  ... 

      ... PORTS                     NAMES
      ... 0.0.0.0:20002->50051/tcp  hw2
      ... 0.0.0.0:20001->50051/tcp  hw1
      ... 0.0.0.0:10003->50051/tcp  rg3
      ... 0.0.0.0:10002->50051/tcp  rg2
      ... 0.0.0.0:10001->50051/tcp  rg1

1. 装置编程语言的先决条件，其中一些可能已装置在测试环境中。

对于 Ubuntu 和 Debian，运行：

$ sudo apt-get install golang-go python3 python-pip git

对于 CentOS、RHEL 和 Oracle Linux，运行：

$ sudo yum install golang python python-pip git

请留神，python-pip 须要启用 EPEL 存储库（依据须要先运行 sudoyuminstallepel-release）。

2. 下载 helloworld 利用：

$ go get google.golang.org/grpc

3. 下载 RouteGuide 利用：

$ git clone -b v1.14.1 https://github.com/grpc/grpc
$ pip install grpcio-tools

1. 运行 helloworld 客户端：

$ go run go/src/google.golang.org/grpc/examples/helloworld/greeter_client/main.go

2. 运行 RouteGuide 客户端：

$ cd grpc/examples/python/route_guide
$ python route_guide_client.py

3. 查看 NGINX 日志，确认测试环境可失常运行：

$ tail /var/log/nginx/grpc_log.json

想要更及时全面地获取 NGINX 相干的技术干货、互动问答、系列课程、流动资源？

请返回 NGINX 开源社区：

官网：https://www.nginx.org.cn/
微信公众号：https://mp.weixin.qq.com/s/XVE5yvDbmJtpV2alsIFwJg
微信群：https://www.nginx.org.cn/static/pc/images/homePage/QR-code.png?v=1621313354
B 站：https://space.bilibili.com/628384319

关于nginx:将-NGINX-部署为-API-网关第-3-部分发布-gRPC-服务

定义 gRPC 网关

运行示例 gRPC 服务

路由 gRPC 申请

准确路由

响应谬误

应用 gRPC 元数据验证客户端

施行健康检查

利用速率限度和其余 API 网关管制

总结

附录：设置测试环境

装置 NGINX 开源版或 NGINX Plus

装置 Docker

装置 RouteGuide 服务容器

装置 helloworld Service 容器

装置 gRPC 客户端利用

测试设置

更多资源