每秒处理 35 万个请求并将数据保存到 Google 云存储
Process 350k requests per seconds and save data to Google Cloud Storage
我需要实现在逻辑和架构方面相当简单的微服务,但需要每秒处理大约 305k 个请求。
它要做的就是摄取 JSON 数据,根据简单的规则对其进行验证,并以 JSON 文件的形式记录到 Google 云存储中。有很多 Google 云服务和 API 可用,但我很难选择合适的堆栈和管道,因为我对它们以及高负载没有太多经验。
我正在看一个例子
https://cloud.google.com/pubsub/docs/pubsub-dataflow
流程如下:
PubSub > Dataflow > Cloud Storage
它完全满足我的需要(日期验证除外),但看起来 Dataflow 仅限于 Java 和 Python,我宁愿使用 PHP.
另一个相关的例子是
https://medium.com/google-cloud/cloud-run-using-pubsub-triggers-2db74fc4ac6d
它使用 Cloud 运行,支持 PHP 和 PubSub 来触发 Cloud 运行 工作负载。所以它是这样的:
PubSub > Cloud Run
在 运行 中使用云存储看起来非常简单。
我走的路对吗?上面提到的东西对我有用还是我需要不同的东西?
当我看到每秒 350k 请求和 PubSub 时,我的第一直觉是这种模式:
Pubsub > Dataflow > BigTable
我的问题验证了 BigTable 的选择,因为 you can query BigTable table from BigQuery 供以后分析。
当然,它很贵,但你有一个非常可扩展的系统。
另一种选择,如果您 process fits the BigQuery streaming quotas, is to stream directly into BigQuery instead of BigTable。
Pubsub > Dataflow > BigQuery
Cloud 运行 或 App Engine 的解决方案的问题是,您将需要 运行 一个外部进程(例如使用 Cloud Scheduler),在这个过程中,您将执行循环以从 PubSub 订阅中提取消息。你会应付几个困难
- PubSub 执行至少 1 次传递和双重消息可能是一个问题。 Dataflow 自动管理这个
- App Engine 和 Cloud 的内存限制 运行 可能是个问题,尤其是当您的语言内存效率不高时。
- 拉动速度可能是一个问题,并行性可能是一个挑战。
- 拉取持续时间限制为几分钟(因为云 运行 和 App Engine 上的最大请求持续时间),您必须优雅地退出并等待下一个 Cloud Scheduler 触发器再次开始 PubSub 拉取。
编辑
我忘了您不想在 Java 或 Python 中编码。如果您的过程真的很简单,我可以向您推荐 2 个备选方案:
- 使用Google provided Dataflow template, especially in streaming where you can stream directly into BigQuery, without transformation. And if you want to perform transform, you can use the source code as base and just add your transform step in it.
- 你可以process your PubSub messages as a simple SQL query。设置起来很无聊,但您只需用 SQL 语言定义您的转换,数据流就会为您构建。
个人观点:编码语言无所谓,用对的工具干对的事。与学习如何编写 10 行 Java 代码
相比,为此使用 Cloud 运行 或 App Engine 将创建一个更加不稳定且难以维护的系统
我需要实现在逻辑和架构方面相当简单的微服务,但需要每秒处理大约 305k 个请求。
它要做的就是摄取 JSON 数据,根据简单的规则对其进行验证,并以 JSON 文件的形式记录到 Google 云存储中。有很多 Google 云服务和 API 可用,但我很难选择合适的堆栈和管道,因为我对它们以及高负载没有太多经验。
我正在看一个例子 https://cloud.google.com/pubsub/docs/pubsub-dataflow
流程如下:
PubSub > Dataflow > Cloud Storage
它完全满足我的需要(日期验证除外),但看起来 Dataflow 仅限于 Java 和 Python,我宁愿使用 PHP.
另一个相关的例子是 https://medium.com/google-cloud/cloud-run-using-pubsub-triggers-2db74fc4ac6d
它使用 Cloud 运行,支持 PHP 和 PubSub 来触发 Cloud 运行 工作负载。所以它是这样的:
PubSub > Cloud Run
在 运行 中使用云存储看起来非常简单。
我走的路对吗?上面提到的东西对我有用还是我需要不同的东西?
当我看到每秒 350k 请求和 PubSub 时,我的第一直觉是这种模式:
Pubsub > Dataflow > BigTable
我的问题验证了 BigTable 的选择,因为 you can query BigTable table from BigQuery 供以后分析。
当然,它很贵,但你有一个非常可扩展的系统。
另一种选择,如果您 process fits the BigQuery streaming quotas, is to stream directly into BigQuery instead of BigTable。
Pubsub > Dataflow > BigQuery
Cloud 运行 或 App Engine 的解决方案的问题是,您将需要 运行 一个外部进程(例如使用 Cloud Scheduler),在这个过程中,您将执行循环以从 PubSub 订阅中提取消息。你会应付几个困难
- PubSub 执行至少 1 次传递和双重消息可能是一个问题。 Dataflow 自动管理这个
- App Engine 和 Cloud 的内存限制 运行 可能是个问题,尤其是当您的语言内存效率不高时。
- 拉动速度可能是一个问题,并行性可能是一个挑战。
- 拉取持续时间限制为几分钟(因为云 运行 和 App Engine 上的最大请求持续时间),您必须优雅地退出并等待下一个 Cloud Scheduler 触发器再次开始 PubSub 拉取。
编辑
我忘了您不想在 Java 或 Python 中编码。如果您的过程真的很简单,我可以向您推荐 2 个备选方案:
- 使用Google provided Dataflow template, especially in streaming where you can stream directly into BigQuery, without transformation. And if you want to perform transform, you can use the source code as base and just add your transform step in it.
- 你可以process your PubSub messages as a simple SQL query。设置起来很无聊,但您只需用 SQL 语言定义您的转换,数据流就会为您构建。
个人观点:编码语言无所谓,用对的工具干对的事。与学习如何编写 10 行 Java 代码
相比,为此使用 Cloud 运行 或 App Engine 将创建一个更加不稳定且难以维护的系统