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 个作业中的每一个,并且仍然可以获得您的整体工件。