dockerizing Java Springboot 应用程序的优势？

Question

我们正在使用 dockerized kafka 环境。我想知道在这种场景中部署 kafka-connectors 和 kafka-streams 应用程序的最佳实践。目前，我们将每个连接器和流部署为 springboot 应用程序，并作为 systemctl 微服务启动。我没有发现对每个 kafka 连接器和流进行 dockerizing 的显着优势。请为我提供相同的见解

Answer 1

对我来说，Docker 与非 Docker 的问题归结为“您的运营团队或组织支持什么？”

Dockerized 应用程序的优势在于它们的外观/行为都相同：docker runJava 应用程序与docker runRuby 应用程序的方式相同。与使用 systemd 运行程序的方法一样，通常没有围绕“我如何运行这个东西？”的通用抽象层。

Dockerized 应用程序还可以抽象一些小的操作细节，例如端口管理 - 即确保您的所有应用程序management.port不会相互冲突。Docker 容器中的应用程序将作为容器内部的一个端口运行，您可以expose将该端口作为外部的其他端口。（随机或您选择的一个）。

根据基础设施的支持，当服务达到一定容量时，普通的 Docker 调度程序可能会自动扩展服务。但是，在 Kafka 流应用程序中，并发性受到 Kafka 主题中分区数量的限制，因此扩展只会意味着您的消费者组中的一些消费者处于空闲状态（如果分区数量多的话）。

但它也增加了复杂性：如果你使用 RocksDB 作为你的本地存储，你可能希望将它保存在（一次性的，可能是只读的！）容器之外。因此，您需要弄清楚如何在操作上/组织上进行卷持久性。使用带有 Systemd 的普通 ol' Jars ......好吧，你总是有硬盘驱动器，如果服务器崩溃，它要么会重新启动（物理机器），要么希望它会被某个实例块存储东西恢复。

我的意思是说：kstream 应用程序不是无状态的 Web 应用程序，其中自动缩放将始终为您提供更多功能，并提供 HTTP 流量。在组织或运营层面做出这些决定的人可能并不完全了解这一点。再说一次，嘿，如果每个人都写 Docker 的东西，那么组织/运营团队“只是”有一些 Docker 调度程序集群（如 Kubernetes 集群或 Amazon ECS 集群）来管理，而不必再直接管理 VM。