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