Spark 批处理为我们的业务带来了很多价值，因为它非常容易水平扩展(我们将 AWS EMR 与 YARN 结合使用)。
然而，随着我们最新的专有解决方案遵循微服务架构，新的挑战出现了。到目前为止，有~230 个微服务充当生产者，其中事件存储在 Kafka 中(这意味着 ~230 个 Kafka 主题)。
尽管我们已经设法验证了使用 Spark 流式处理作为事件处理来构建对象的最新状态，但我说的每个 Kafka 主题都需要一个 Spark 流式处理应用程序(因此，~230 个应用程序)是否正确？
如果是这样，我们具有48 个 vCPU和192GiB 内存的集群只能同时处理52 个流处理应用程序。这听起来太少了，因为这些应用程序(需要运行 24 小时)并没有做太多事情，因为它们只是每 5 秒拉取一次事件并针对我们的数据存储执行 CRUD 操作。
我是否想念使用 Spark 流式处理？您还会采取/使用什么其他方法或框架？
这听起来不对，您的微服务不需要 230 个主题，也不需要 230 个 Spark 流式处理应用程序，但是您将为每个分区使用 1 个任务，这意味着您需要 230*(每个主题的分区)内核来运行您决定构建的 230 或 1 个应用程序，请注意，这取决于流量，但您的最佳选择可能是只有 1 个主题或一组较小的主题， 按消耗进行筛选。您可以订阅任意数量的主题。 至于用于构建状态存储的内容，您可以查看 kafka 流或 akka 流。我根本不建议将 Spark 流用于生产应用程序(此声明符合自以为是的条件)。Akka 流是最简单的 API 使用 IMO，您可能需要在其上编写商店和 API 代码。