python - 将 proto 缓冲区转换为 ProtoRPC

Question

在 Python 脚本中，mylibrary.py , 我用 Protocol Buffers使用以下方法对数据建模:

在 .proto 文件中定义消息格式。

使用 Protocol Buffer 编译器。

使用 Python Protocol Buffer API 在 .py 模块中写入和读取消息。

我要实现 Cloud Endpoints Framework on App Engine那个 imports并使用上述 Python 脚本，但 Cloud Endpoints 使用 ProtoRPC ，不是“标准” Protocol Buffers .

我的 App Engine Python 模块， main.py , 进口自 protorpc而不是使用“离线” protoc编译器生成序列化和反序列化代码:

from protorpc import messages
from protorpc import remote

留言是 不是 使用 .proto 定义文件。相反，定义了类，继承自 protorpc.messages.Message :

class MyMessageDefinition(messages.Message)

Proto Buffers 可以转换为 Proto RPC 等价物吗？我真的不想改变 mylibrary.py使用 ProtoRPC，因为它不如 Protocol Buffers 通用.

Answer 1

经过八个月的大量实验，我会补充我的意见。我希望它可以节省某人的时间。

首先选择您的框架

Google Cloud 提供不同的 Cloud Endpoint 产品。所有这些都可以用于 JSON/REST API。这对我来说并不是很清楚。 Cloud Endpoints是一个非常高级的短语，涵盖了 上 API 的开发、部署和管理。多个 谷歌云后端。

这里的重点是，在决定使用 Cloud Endpoints 之后，您仍然必须决定后端技术来为您的 API 提供服务。文档感觉有点隐蔽，但我强烈建议从 Google Cloud Endpoints doc 开始.

您可以选择:

OpenAPI Specification

Endpoints Frameworks

gRPC

选择您的第二个实现

在每个 API 框架中，您可以选择运行 API(服务)的云实现:

OpenAPI Specification
- 对于 JSON/REST 实现的 API:

Google App Engine 柔性环境

谷歌计算引擎

谷歌容器引擎

Kubernetes

Endpoints Frameworks
- 对于 JSON/REST 实现的 API:

使用 Java 的 Google App Engine 标准环境

使用 Python 的 Google App Engine 标准环境

gRPC
- 对于 gRPC 实现的 API:

谷歌计算引擎

谷歌容器引擎

Kubernetes

在这里发布问题时，我使用的是 Endpoints Frameworks使用 Python 在 Google App Engine 标准环境中运行。然后我将我的 API(服务)迁移到 Google Compute Engine 上的 gRPC。

细心的您可能会注意到 OpenAPI Specification和 Endpoints Frameworks可用于 JSON/REST API，而 gRPC只公开一个 gRPC API。那么我是如何从 Endpoints Frameworks 移植我的 REST API 的？至 gRPC ?答案是 Transcoding HTTP/JSON to gRPC (这是我一路上学到的，对我来说并不是很清楚)。所以，不要仅仅因为你想要 REST/HTTP 就排除 gRPC。

答案

那么这与我原来的问题有什么关系呢？

我试图在 .proto 之间转换文件和 gRPC 注释，这意味着我一路走错了路。

如果您想使用普通 .proto 编写应用程序文件，然后选择 gRPC在计算引擎上。如果您需要将其作为 REST API，则可以这样做，但您需要添加 ESP进入您的后端配置。这几乎是一个 NGINX服务器设置为反向代理。唯一的缺点是你需要一些 Docker 知识来确保 ESP(代理)和你的 gRPC 服务器可以通信(Docker 网络)。

如果您的代码已经在 App Engine 上，并且您希望以最少的努力将其公开为 REST API 并仍然获得良好的 API 管理功能，请选择 Endpoints Frameworks . 警告:我放弃了这个，因为它太贵了(我每月收取 100 美元的费用)。

如果你想避免 .protos一共，然后去 OpenAPI Specification .

最后，如果您想提供程序化集成、客户端库，或者您想提供 microservice ，那么真的要考虑 gRPC .删除 ESP(代理)并在几乎任何机器上运行 gRPC 服务器都很容易(只要安装了 Protocol Buffer Runtime。

最终，我在 Compute Engine 上使用 Docker 选择了 gRPC。我还有一个 ESP 来为 gRPC 提供 HTTP 转码，反之亦然。我喜欢这种方法有几个原因:

你学到了很多东西:Docker、Docker 网络、NGINX 配置、 Protocol Buffer 、ESP(云代理)、gRPC 服务器。

服务(核心业务)逻辑可以用普通的 gRPC 编写。这允许该服务在没有 Web 服务器的任何机器上运行。您的业​​务逻辑，是服务器:)

Protocol Buffers/gRPC 非常适合将业务逻辑隔离为服务……或微服务。它们还有助于提供定义良好的接口(interface)和库。

避免这些错误

实现您找到的第一个框架/架构。如果可以重新开始，我不会选择Endpoints Frameworks .它很昂贵，并且使用注释而不是 .proto文件，IMO 使代码更难移植。

阅读 Always Free Usage Limits在决定框架和实现之前。 Endpoints Frameworks用途 后端 App Engine 实例 - 几乎没有免费配额。令人困惑，前端 App Engine 实例有一个非常generous free quota .

考虑本地开发。 Cloud Endpoints 本地开发服务器不受官方支持(至少在我提出问题时不支持)。相反，在运行 Local Extensible Service Proxy 上有一整页.