我们目前正在评估我们在Google Cloud Platform上的选项,以寻求一种可通过这种方式运行的解决方案。我们期望应用程序会发送很多消息,并且打算使用google cloud pub / sub将这些交易排队。现在,典型的消息中可以包含多个JSON对象,如下所示:
{
groupId: "3003030330",
groupTitle: "Multiple Payments Processing",
transactions: [
{id: "3030303" , amount: "2000" , to: "XXXX-XXX"},
{id: "3030304" , amount: "5000" , to: "XXXX-XXX"},
{id: "3030304" , amount: "5000" , to: "XXXX-XXX"},
]
}
现在,我们需要使用谷歌云数据流将这些交易中的每一个同步并并行地传递到我们的支付网关,然后将响应整理到另一个PCollection中,并将其写入另一个pub / sub主题。 我的困惑是,如果Google Cloud Dataflow是解决此问题的最有效和可扩展的解决方案,还是使用Kubernetes HorizontalPodAutoScaler根据发布/订阅队列中的消息进行扩展。任何想法和想法都将不胜感激。
答案 0 :(得分:0)
默认情况下,Cloud Dataflow可以auto-scale从1到1000个实例,每个实例具有4个vCPU,15GB内存和420GB永久磁盘,因此,如果您有足够的配额,则可以扩展到4,000个核心, 15,000 GB的内存和420 TB的存储使用量。
但是,当前有一个Streaming Engine的beta版本,该版本通过将管道执行移出辅助VM并移至Cloud Dataflow服务后端,根据传入数据量的变化提供了更灵敏的自动扩展。这样,它在较小的工作者计算机类型上效果最佳,并使用较少的存储空间。
答案 1 :(得分:0)
我会使用DataFlow或新的Streaming Engine,我认为它很像Apache Spark Streaming或Apache Flink Streaming。所有这些的缺点可能是GCP供应商锁定。
尽管有多种用于Kubernetes的工具,并且它可能工作正常,但维护环境会产生额外的成本。例如。确保您的广告连播/部署顺利进行等,并学习/投资在集群上运行Spark / Flink流。另外,Kubernetes还没有在许多生产大数据管道中经过严格的测试。此解决方案的好处是没有供应商锁定。
我的两分钱。