Google cloud storage 每秒处理350k请求并将数据保存到Google云存储

我需要实现microservice，它在逻辑和架构方面相当简单，但每秒需要处理大约305k个请求

它所要做的就是接收JSON数据，根据简单的规则进行验证，并将其作为JSON文件记录到Google云存储中。有很多Google云服务和API可用，但我很难选择合适的堆栈和管道，因为我对它们以及高负载没有太多经验

我正在看一个例子

流程如下所示：

PubSub > Dataflow > Cloud Storage

它完全符合我的需要（除了日期验证），但看起来数据流仅限于Java和Python，我更愿意使用PHP

另一个相关的例子是

它使用云运行、支持PHP和PubSub来触发云运行工作负载。所以它是这样的：

PubSub > Cloud Run 

在运行中使用云存储看起来非常简单

---

我走对了吗？上面提到的东西对我有用吗？或者我需要一些不同的东西吗？

当我看到每秒350k请求和PubSub时，我的第一个直觉是：

Pubsub > Dataflow > BigTable

我的问题验证了BigTable的选择，因为为了以后的分析

当然，这是昂贵的，但你这里有一个非常可扩展的系统

另一种选择，如果你的

Cloud Run或App Engine解决方案的问题在于，您将需要在外部运行一个进程（例如，使用Cloud Scheduler），在此过程中，您将执行一个循环以从PubSub订阅中提取消息。你将应付几个困难

• PubSub至少执行一次传递，可能会出现双重消息。数据流会自动管理这个
• App Engine和Cloud Run的内存限制可能是一个问题，特别是如果您的语言内存不足
• 拉速可能是一个问题，并行性可能是一个挑战
• 拉取持续时间限制为几分钟（因为云运行和应用引擎上的最大请求持续时间），您必须优雅地退出，并等待下一个云调度程序触发器再次启动PubSub拉取

编辑

我忘了您不想用Java或Python编写代码。如果您的流程非常简单，我可以向您推荐两种备选方案：

• 使用，特别是在流式处理中，您可以直接流式处理到BigQuery，而无需转换。如果要执行转换，可以使用
• 你可以。设置起来很无聊，但您只需用SQL语言定义转换，数据流就是为您构建的

---

个人观点：编码语言无关紧要，使用正确的工具完成正确的工作。与学习如何编写10行Java代码相比，使用Cloud Run或App Engine将创建一个更不稳定、更难维护的系统

您希望为每个请求创建一个文件还是将请求is消息分组（例如每分钟一个文件）？你的文件的目的是什么？之后您将如何处理它们？最好的选择是将消息分组为固定大小的间隔（如第二个示例所示）。文件用作原始数据存储，供以后与BigQuery一起使用。但目前这并不是必要的。现在，选择合适的服务是无能为力的。我们是否应该使用App Engine或Cloud Run倾听请求？还是最好直接发布到PubSub（以及接下来的内容，GAE，GCR）…谢谢您的回答。数据流很好，但看起来它只支持Java和Python。难道不可能触发由PubSub直接运行的应用程序引擎和/或云，从而摆脱云调度器和通过消息的循环吗？我用2个数据流低代码解决方案编辑了我的答案。我对做不标准的事情的看法，再一次，我的看法，不好的理由（语言）

Pubsub > Dataflow > BigQuery