修改Java Springboot应用程序的优势？

Question

我们的工作环境是一个被篡改的卡夫卡。我想知道在这种场景中部署kafka连接器和kafka流应用程序的最佳实践。目前，我们正在将每个连接器和流部署为springboot应用程序，并作为systemctl微服务启动。我不认为在对接每个卡夫卡连接器和流明显的优势。请给我提供同样的见解。

Answer 1

对我来说，码头与非码头的关系归结为“你的运营团队或组织支持什么？”

文档化的应用程序有一个优点，因为它们看起来/行为都是一样的:您的docker run应用程序与docker run应用程序的方式相同。与使用systemd运行程序的方法一样，在“我如何运行这个东西”周围通常没有一个通用的抽象层。

文档化的应用程序也可能抽象一些小的操作细节，例如端口管理--即确保应用程序的management.port不相互冲突。Docker容器中的应用程序将作为容器内的一个端口运行，您可以将该端口作为外部的其他数字来运行。(不是随机的，就是你自己选择的)。

根据基础设施支持，正常的码头调度程序可以在服务达到一定容量时自动缩放该服务。但是，在Kafka streams应用程序中，并发性受到Kafka主题中分区数量的限制，因此，扩展只意味着您的消费者组中的一些消费者处于闲置状态(如果分区的数量超过)。

但这也增加了复杂性:如果您使用RocksDB作为本地商店，您很可能希望将其保存在(一次性的，也许是只读的！)之外。容器。因此，您需要弄清楚如何在操作/组织上进行卷持久化。用普通的罐子和系统..。那么，您总是有硬盘驱动器，如果服务器崩溃，它将重新启动(物理机器)或希望它将被某个实例块存储恢复。

我想说的是: kstream应用程序不是无状态的，自动缩放的web应用总是会给你更多的权力，并且为HTTP流量服务。在组织或业务层面上作出这些决定的人可能不完全了解这一点。再说一遍，如果每个人都写Docker的东西，那么组织/操作团队“只是”有一些Docker调度程序集群(比如Kubernetes集群，或Amazon集群)来管理，而不必再直接管理VM了。

Answer 2

使用kubernetes进行Dockerizing+集群提供了许多好处，如自动愈合、自动水平缩放。

自动恢复：如果春季应用程序崩溃，kubernetes将自动运行另一个实例，并将确保所需的容器数量始终处于上升状态。

自动水平缩放：如果您收到大量消息，yo可以使用HPA对spring应用程序进行调优，使其自动向上或向下扩展，这也可以使用自定义度量。