我们可以有后台批处理的微服务架构吗? [英] Can we have micro service architecture for background batch processing?

问题描述

最近我开发了一个 spring 批处理应用程序，其中配置了 3 个作业.只需部署一个 jar 即可完成三个 3 工作.

Recently i developed a spring batch application which has 3 jobs configured in it. Only one jar needs to be deployed to perform three 3 jobs.

如果我们有另一个业务需求，我很乐意在现有配置中添加一个新作业，它会正常工作.我们不会为此作业创建单独的 jar.

If we get another business requirement , I would happily add a new job in existing configuration and it will work fine. We will not create a separate jar for this job.

我正在学习一些微服务教程.我注意到我们为每个微服务创建了单独的代码存储库.在 Spring Batch 中，我们将所有作业添加到一个 jar 中，尽管它们是独立的作业，例如小型微服务.

I was going through some micro service tutorials. I noticed that we create separate code repository for each micro service. In spring batch we add all jobs in one jar only though they are independent jobs like small micro services.

我的问题是，我们是否也应该为后台批处理提供微服务类型的架构或代码存储库?如果是，我们是否必须为每个作业创建单独的存储库?如果不是，那为什么?

My questions is , Should we have micro service kind of architecture or code repository for background batches as well? if yes , do we have to create separate repository per job ? If not then why ?

提前致谢.

推荐答案

在单个 jar 中打包多个独立作业首先违背了微服务方法.没有什么可以阻止您为所有作业使用一个代码存储库，但出于以下原因，我不会将它们打包在一个 jar 中:

Packaging multiple independent jobs in a single jar goes against the micro-services approach in the first place. Nothing prevents you from having a single code repository for all jobs, but I would not package them in a single jar for the following reasons:

• 独立的生命周期:如果您在工作中修复了一个大的，您不需要重新部署包含所有其他(未受影响)工作的单个单体 jar
• 版本控制:工作可能以不同的速度发展.一个 jar 包含不同版本的不同作业并不理想
• 占用空间小:与每次传输一个胖 jar 相比，必须部署一个小 jar 来更新单个作业在网络使用方面更好、更高效.
• 以及让一件事做一件事并把它做好的所有其他充分理由

这篇关于我们可以有后台批处理的微服务架构吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！