从 spring-batch-admin 迁移到 spring 云数据流

Posted 2023-02-16

【中文标题】从 spring-batch-admin 迁移到 spring 云数据流

【英文标题】：Migrating from spring-batch-admin to spring cloud dataflow

【发布时间】：2018-02-05 18:59:53

【问题描述】：

我们计划从 spring-batch-admin 迁移到 spring-cloud-dataflow，因为批处理管理员将迁移到 Spring Attic，生命周期结束日期为 2017 年 12 月 31 日。

根据Migration Doc 中的文档，“在 Spring Batch 用例中，每个批处理作业都打包为一个独立的 Spring Boot über jar，并在 Spring Cloud Data Flow 中注册” p>

在哪种情况下，如果有 50 个批处理作业，则必须创建 50 个 über jar？这样做将是维护的噩梦，创建许多 jar 并维护它们会很困难。

有什么解决方法吗？所以我们将能够将所有批处理作业打包在单个 über jar 中，并且我们可以在需要时随机启动任何作业？

任何帮助将不胜感激，在此先感谢

【参考方案1】：

TL;DR; 观看我关于将数据处理迁移到微服务的演讲：https://www.youtube.com/watch?v=COzkPkHZMG8。如果在那之后您仍然觉得这是一件坏事，请跳到我提出替代（不推荐）方法的底部。

为什么这是一件好事 让我花一点时间来解释一下为什么我们认为这是一个更好的解决方案，以及为什么我不鼓励你采取单一的方法。毕竟，我会提出一个我不推荐但应该可行的替代方案。

打破整体 如果您考虑大多数企业将批处理功能从开发人员的笔记本电脑交付到生产环境的过程，这通常是一个缓慢的过程，并且不经常发布。这个过程很慢，代码可能需要通过多个组（开发，一些来自外部 QA，可能是某种形式的变更控制过程，最后是某种类型的运营团队来实际部署代码）。通常，需要通过该过程的代码片段越小，通过该过程就越容易。

在此示例中，对于包含 50 个批处理作业的系统，要更改其中一个，您需要使用 所有 个作业完成该过程。将其分解实际上简化了维护，因为您可以独立更改和部署作业。开发人员只需要专注于手头的批处理作业。

迁移到 über jars 从包含所有作业的单个 WAR 文件迁移的另一个优点是灵活性。您可以在任何您想要的基础设施上运行这些作业。想通过java -jar foo.jar 命令在本地或裸机上运行它吗？去吧。想通过cf push 在 CloudFoundry 上运行它吗？你打赌。想要将应用程序 docker 化并在 Kubernetes 上运行？你可以！虽然您可以在不使用 über jar 方法的情况下做同样的事情，但它更加细微，因为基础设施可能会因环境而异。对于 über jar，您只需要保证 java 版本即可。

工件管理也是一个很好解决的问题。将 über jar 推送到 Maven 存储库是一个简单的过程，在整个 Java 环境中都经过了很好的审查。如何管理 WAR 文件真的不是。您可以将它们推送到 Maven 存储库，但这并不理想。通过迁移到 über jars，您的发布过程在所有工作（以及所有应用程序）中变得非常标准化。

最后，迁移到 über jar 应该不会那么难。假设您的工作定义明确，它实际上应该只是一个包装练习。如果不是这样，这是进行一些健康重组的好机会，以便它们首先更加模块化（良好的工程实践）。

替代方法 我想从这里开始说我不推荐这种方法。但是，它应该可以工作。

不要为每个作业创建一个 über jar，而是创建一个包含所有 50 个作业的 über jar。您需要创建自己的CommandLineRunner，它会查看环境变量以确定启动时要运行的作业，并关闭 Spring Boot 功能以在启动时自动执行作业。

从那里，您将通过 Spring Cloud Data Flow 中的 50 个任务定义配置您的 50 个作业。每个都传递指示要运行的作业的环境变量。从那里，您将能够独立执行/监控/等 50 个作业中的每一个，并且仍然可以获得您的整体工件。

【讨论】：

感谢您的回复，微服务方法很棒。但是，可能应该有灵活性将多个作业打包在同一个 jar 中，并且它们可以与 Cloud Dashboard 分开启动？可能有一些用例，例如作业很小，单独的 jar 可能会产生开销。我们的用例是，从 DB2 迁移到 Cassandra，那里大约有 50 个表。计划是为 1 个表写 1 个作业，所以总共 50 个作业。迁移完成后，我们不会使用 90% 的这些工作。所以，我们的想法是生成这么多 jar 是开销，并让我们以通常的单片方式打包。

如果您希望每个作业只处理一个表，为什么不编写一个足够聪明的作业以通过配置处理每个表？这听起来更像是设计问题而不是部署问题。

嗨迈克尔，使用批处理管理，我们希望为每个表（具有相同的读取器/写入器，范围内的作业/步骤）都有一个作业，以便跟踪/启动作业和表从 UI 迁移。现在重新考虑您建议的方法，这是一项可以通过配置处理多个表迁移的智能作业。并且计划是为每个表添加一个任务定义，所以这里我们将在任务定义级别区分迁移。非常感谢您的支持:)

【参考方案2】：

除了“替代方法”之外，您可以在执行单个单一的 50 个作业的 jar 文件时提供一个选项来执行您想要的确切作业。

java -jar single.jar -Dspring.batch.job.names=jobName