1

我有一个专门用于批处理的 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 为核心

所以我的问题是，根据上述细节，避免业务逻辑重复的可接受方法是什么？可以/应该改变架构以更好地适应这一点吗？

另一个需要考虑的想法是这会是什么样子以及“微服务”架构。这个词在办公室里被反复讨论过很多次，我们一直在考虑将主要的 Web 应用程序分解为服务的想法。例如，我们最终可能会提供用户管理服务。

4

2 回答 2

0

Say for example you are using a Java EE 6 application.

Your CSV batch updater could be nothing more than a Timer that every once in a while reads a CSV file dumped in a folder and for each user update encoded on that file pumps a message to a queue encoding the update you want to do.

Somewhere else, you have a message driven bean that reacts to the update request message and triggers the update business logic for the user reported on the JMS message.

After the transaction is committed successfuly, if you have ten differn application that are interested in knowing that the user was updated, you could post a message to, for example, a notification topic with - say - messageType='userUpdated'. Each of your 10 applications that cares about this could be a consumer on this topic. They would be informed that a user was updated and maybe internally publish a local event (e.g. a CDI event - a guava event - whatever - and the internal satke holders would now of it).

Normally, there are always Java EE replacements in every technlogy stack. Every decent technology stack offers ways to promote loose coupling between UI and business logic, precisely so that HTML / WEB is just viewed as one of many entry points to an application's business logic.

In scala, i there is an AKKA framework that looks super interesting.

The point is, as long as your business logic is not written in some place that only the web application can tap into, your fine. Otherwise, you've made the design decision to couple your business logic with UI.

于 2014-12-14T15:44:16.740 回答
0

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

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

于 2014-12-16T22:37:25.993 回答