对 gRPC 架构的担忧（gRPC、nginx、docker）答案

【问题标题】：Concerns with gRPC architecture (gRPC, nginx, docker)对 gRPC 架构的担忧（gRPC、nginx、docker）
【发布时间】：2020-11-02 06:42:02
【问题描述】：

我目前正在尝试创建一个有趣的跟踪工具（它支持 gRPC 跟踪），并且对我是否正确地考虑了这个架构感到困惑。跟踪工具跟踪请求的整个工作流程/旅程（从用户单击按钮的那一刻到请求到达 API 网关、微服务之间以及返回的时间。

假设应用程序是一个书店，它被分解为 2 个微服务，可能是帐户和书籍。假设有一个用户界面，当您单击一个按钮时，它允许用户收藏一本书。我只使用了 2 个微服务来简化这个示例。

**Different parts of the Fake/Mock up application**
UI -> 
nginx -> I wanted to use this as an API Gateway.
microservice 1 -> (Contains data for all Users of a bookstore) 
microservice 2 -> (Contains data for all the books)

**所以我的目标是找到一种方法来跟踪该请求。所以我们可以想象请求到了 nginx

关注点 #1： 当请求到达 nginx 时，它是 HTTP。很酷，但是当请求发送到微服务时，它是一个 grpc 调用（或通过 http2）。 nginx 可以获取一个 http 请求，然后通过 http2 发送该请求......？不确定我的措辞是否正确。我知道 nginx plus 支持 http2。我也知道grpc也有grpc网关。

关注点 2： 容器化。我是否必须单独容器化这两个微服务，还是必须将整个 docker 容器本身容器化。连接nginx和docker简单吗？

关注点 #3： 在跟踪 gRPC 请求时（了解请求完成的时间），我正在考虑使用中间件记录器或跟踪 API（opentracing、jaegar 等）去做这个。否则我怎么知道 gRPC 发出请求需要多长时间？

我想知道是否有可能解决这些问题，我的思考过程是否正确，以及此架构是否具有功能。

【问题讨论】：

标签： docker grpc grpc-java grpc-go grpc-node

【解决方案1】：

业内大多数解决方案都是在容器编排解决方案（Kubernetes、Docker Swarm 等）之上实施的。
自己“容器化”和管理反向代理通常不是一个好主意。
反向代理应该知道所有容器的状态（通过挂钩编排器）并在容器创建、崩溃或重定位（由于机器停止服务）时动态更新其配置。
Kubernetes 使用网状网络处理 GRPC。请看kubernetes service mesh。
如果您决定使用 Traefik 和 Docker Swarm，请查看traefik h2c support。
总之，当您想要对 GRPC 进行负载平衡时，请考虑使用更现代的 Nginx 替代方案。

【讨论】：