经过八个月的大量实验后，我将添加我的意见。我希望它可以节省一些时间。
首先选择你的框架
Google Cloud 提供不同的 Cloud Endpoint 产品。所有这些都可用于 JSON/REST API。这对我来说不是很清楚。Cloud Endpoints是一个非常高级的短语，涵盖了在多个Google Cloud 后端上开发、部署和管理 API。
这里的重点是，在决定使用 Cloud Endpoints 之后，您仍然必须决定使用后端技术来为您的 API 提供服务。文档感觉有点隐蔽，但我强烈建议从Google Cloud Endpoints 文档开始。
您可以选择：
- OpenAPI 规范
- 端点框架
- gRPC
其次选择您的实施
在每个 API 框架中，您的 API（服务）可以在其上运行的云实现可供选择：
OpenAPI 规范
- 用于实现的JSON/REST API：
- Google App Engine 柔性环境
- 谷歌计算引擎
- 谷歌容器引擎
- Kubernetes
端点框架
- 用于实现的JSON/REST API：
- 使用 Java 的 Google App Engine 标准环境
- 使用 Python 的 Google App Engine 标准环境
gRPC
- 用于在以下位置实现的gRPC API：
在这里发布问题时，我使用的是在带有 Python 的 Google App Engine 标准环境上运行的Endpoints Frameworks 。然后，我将我的 API（服务）迁移到 Google Compute Engine 上的 gRPC。
细心的人可能会注意到OpenAPI 规范和端点框架都可以用于 JSON/REST API，而gRPC只公开了一个 gRPC API。那么我是如何将我的 REST API 从Endpoints Frameworks移植到gRPC的呢？答案是将HTTP/JSON 转码为 gRPC（我在此过程中学到了，但我并没有立即清楚）。所以，不要仅仅因为你想要 REST/HTTP 就排除 gRPC。
答案
那么这与我原来的问题有什么关系呢？
我试图在.proto文件和 gRPC 注释之间进行转换，这意味着我走错了路。
如果您想使用普通.proto文件编写应用程序，请在 Compute Engine 上选择gRPC 。如果您需要将其作为 REST API，则可以这样做，但您需要将ESP添加到后端配置中。它几乎是一个NGINX服务器设置作为反向代理。这里唯一的缺点是你需要一些 Docker 知识来确保 ESP（代理）和你的 gRPC 服务器可以通信（Docker 网络）。
如果您的代码已经在 App Engine 上，并且您希望以最小的努力将其公开为 REST API，并且仍然获得良好的 API 管理功能，请选择Endpoints Frameworks。警告：我放弃了这个，因为它太贵了（我每月的账单是 100 美元左右）。
如果您想.protos完全避免，请使用OpenAPI Specification。
最后，如果您想提供程序化集成、客户端库，或者您想提供微服务，那么请考虑gRPC。移除 ESP（代理）并在几乎任何机器上运行 gRPC 服务器都很容易（只要安装了Protocol Buffer Runtime 。
最终，我在 Compute Engine 和 Docker 上选择了 gRPC。我还有一个 ESP 来为 gRPC 提供 HTTP 转码，反之亦然。我喜欢这种方法有几个原因：
- 你会学到很多：Docker、Docker 网络、NGINX 配置、协议缓冲区、ESP（云代理）、gRPC 服务器。
- 服务（核心业务）逻辑可以用普通的 gRPC 编写。这允许该服务在没有 Web 服务器的任何机器上运行。您的业务逻辑是服务器:)
- Protocol Buffers / gRPC 非常适合将业务逻辑隔离为服务……或微服务。它们也很适合提供定义良好的接口和库。
避免这些错误