我们正在使用dockerized kafka环境。我想知道在这样的场景中部署kafka-connectors和kafka-streams应用程序的最佳实践。目前，我们正在将每个连接器和流部署为springboot应用程序，并作为systemctl微服务启动。我没有找到对每个kafka连接器和流进行docker化的重要优势。请提供相同的见解
答案 0 :(得分：3)
对我而言，Docker vs非Docker的事情归结为“您的运营团队或组织支持什么？”
Dockerized应用程序的优势在于它们看起来/行为相同：您docker run Java应用程序的方式与您使用Ruby应用程序docker run的方式相同。在使用systemd运行程序的方法中，通常没有一个共同的抽象层围绕“我该如何运行这个东西？”
Dockerized应用程序还可以抽象一些小的操作细节，例如端口管理 - 即确保所有应用程序的management.port不会相互冲突。 Docker容器中的应用程序将作为容器内的一个端口运行，您可以expose将该端口作为外部的其他数字。 （随机，或者您选择的一个）。
根据基础架构支持，正常的Docker调度程序可能会在该服务达到某个容量时自动扩展服务。但是，在Kafka流应用程序中，并发性受到Kafka主题中分区数量的限制，因此向上扩展只会意味着消费者组中的某些消费者空闲（如果分区数量超过分区数）。
但它也增加了复杂性：如果你使用RocksDB作为你的本地商店，你可能想要在（一次性的，也许只读！）容器之外保留它。因此，您需要弄清楚如何在操作/组织上执行卷持久性。使用简单的'带有Systemd的罐子......好吧，你总是有硬盘驱动器，如果服务器崩溃，它将重新启动（物理机器）或希望它将被某些实例块存储器恢复。
我的意思是说：kstream应用程序不是无状态的，Web应用程序，其中自动扩展将始终为您提供更多功能，并为HTTP流量提供服务。在组织或运营层面做出这些决策的人可能并不完全了解这一点。然后，嘿，如果每个人都写Docker的东西，那么组织/运营团队“只是”有一些Docker调度程序集群（如Kubernetes集群，或Amazon ECS集群）来管理，而不必再直接管理VM。 / p>
答案 1 :(得分：0)
使用kubernetes进行Dockerizing +集群提供了许多好处，例如自动修复，自动水平扩展。
自动修复：如果Spring应用程序崩溃，kubernetes将自动运行另一个实例，并确保所需数量的容器始终处于运行状态。
自动水平扩展：如果收到大量消息，您可以使用 HPA 调整spring应用程序自动向上或向下扩展，这些 HPA 也可以使用自定义指标。