批处理时如何避免重复业务逻辑？

Question

我有一个专门用于批处理的Web应用程序（这里有批量服务，api驱动），我有一个专门用于其他一切的主要Web应用程序。我一直在努力决定最好的方法是避免批量服务中的业务逻辑重复。两个应用程序都是群集的。对于简单的作业，批处理的分离是可以的，但是我有更复杂的工作，如果业务逻辑重复，它只会导致混乱。这是我用这个问题的用例。

1. 客户安排用户更新的cron作业。
2. 批量服务被赋予一个包含20,000个用户记录的CSV文件。
3. 批处理服务翻录文件，对记录进行验证，基本上是干运行。
4. 批处理服务将检查允许的更改和错误阈值（百分比是计数）
5. 如果验证阈值通过，批处理服务将开始创建/更新用户。
6. 创建或更新用户时，需要了解有关这些事件的许多模块/功能。
7. 跟踪作业进度，客户可以查看进度，日志和作业状态。

以下是我一直在考虑的一些解决方案：

• 制定业务逻辑并在两个应用程序之间共享。这并不是一件容易的事，因为主要的应用程序是Grails应用程序，而且整个过程都有GORM乱码。
• 让批处理服务在主应用程序上点击API以进行创建和更新，以及可能更复杂的验证方案。担心这会对tomcat产生影响，但是调用将通过负载均衡器进行分配。
• 让批处理服务在主应用程序上点击API进行验证，然后排队创建/更新请求并让主应用程序检索它们。与上面相同，队列有助于减少http调用。还需要一个队列来将状态报告回批处理服务。
• 通过让批处理服务执行自己的验证和插入/更新来复制一些逻辑，但随后触发用户创建的事件或用户更新的事件，以便主应用程序中的模块/功能可以处理更改。
• 将批处理服务嵌入主应用程序

其他细节：

• 批处理服务和Web应用程序都是集群的
• 两者都在AWS上运行，因此我可以轻松访问SQS和SNS等工具
• Java 1.7应用程序
• Tomcat容器
• 主要应用是Grails
• 批处理服务使用Spring Batch和Quartz作为其核心

所以我的问题是，基于上述细节，可以接受哪些方法来避免重复业务逻辑？可以/应该更改架构以更好地适应这种情况吗？

另一个需要考虑的想法是它的外观和一个＆＃34;微服务＆＃34;建筑。这个词在办公室被多次抛出，我们一直在考虑将主要的Web应用程序分解为服务的想法。例如，我们最终可能会提供用户管理服务。

Answer 1

例如，假设您使用的是Java EE 6应用程序。

您的CSV批量更新程序可能只是一个计时器，每隔一段时间就会读取一个文件夹中转储的CSV文件，并且对该文件上编码的每个用户更新都会将消息泵送到编码您要执行的更新的队列中

在其他地方，您有一个消息驱动Bean，它响应更新请求消息并触发JMS消息上报告的用户的更新业务逻辑。

在成功提交事务之后，如果您有十个不同的应用程序有兴趣知道用户已更新，您可以发布消息，例如，通知主题，例如 - messageType =＆＃39; userUpdated＆＃39 ;. 您关心此问题的10个应用程序中的每一个都可以成为该主题的消费者。 他们会被告知用户已更新，并可能在内部发布本地事件（例如CDI事件 - 番石榴事件 - 无论如何 - 内部的satke持有者现在都会这样做。）

通常，每个technlogy堆栈中始终存在Java EE替换。 每个体面的技术堆栈都提供了促进UI和业务逻辑之间松散耦合的方法，正是为了使HTML / WEB被视为应用程序业务逻辑的众多入口点之一。

在scala中，我有一个非常有趣的AKKA框架。

关键是，只要您的业务逻辑没有写在只有Web应用程序可以访问的某个地方，您的罚款就可以了。否则，您已做出设计决策，将业务逻辑与UI结合起来。

Answer 2

在你的情况下，我建议关注分离，我的意思是一个插件只收集域类，如果使用Grails，其他插件负责服务......这些代表应用程序核心，我如果您的应用程序包含太多的KLOC，那么这种方式会更容易，如果模块之间有很多调用，使用微服务将花费您太多时间。

功能模块之间的通信。插件可以通过事件制作，参见events-si或rabbit MQ插件。