mysql - Jboss/MySQL 垂直部署的优缺点

Question

我正在开发一个项目，每个应用程序都有一个 WAR 文件，它就像一个应用程序商店。
因此，10 个应用程序部署了 10 个不同的 WAR 文件。通常，WAR 文件内有一个 DAO、BL 作为单独的 jar 包，用于公开 Web 服务。
然而，在极少数情况下，我们会引用另一个 WAR 文件中的库(通常是 DAO/BL)。
我不确定这是否是正确的方法。我们在部署时似乎遇到了困难，以确定所使用的已部署 JAR 的版本等。另一种方法是不与另一个应用程序的 JAR(DAO)对话，而是在需要时与客户端部署的 Web 服务对话。

DAO 有一个 MySQL 数据库的 mysql-ds.xml。
我们可以为所有功能提供一个数据源，但不确定它是否有帮助。

正如您从我的上一段中可以看出的那样，我有点困惑，并且担心如果我们有 100 个不同的应用程序，那么维护所有 100 个应用程序及其依赖项将非常困难。另外如何从jboss中有效地使用连接池？为所有应用程序使用单个数据库还是多个数据库会很好吗？这是在维护方面？我们的堆栈是

Jboss
Apache CXF
Dozer 
DAO (Hibernate)
Entity (POJO)
Hibernate
Mysql

以及maven作为构建工具。我知道我的问题有点笼统，如果您需要更多信息，请告诉我。

Answer 1

像这样复杂的基础设施总是难以管理。

您可以采取三种主要方法，每种方法都有优点和缺点:

1. Web 服务将所有业务层/数据访问封装到 API 中。这可以最大限度地减少各种应用程序中 jar 版本的激增，但会迫使您对 API 更改更加严格。
2. 创建可以在多个项目之间共享的库。我不清楚你引用另一个 WAR 文件中的库是什么意思，也许这就是你在新部署的 WAR 中包含相关 jar 的意思。这确实会导致您提到的版本兼容性问题，但可以使修改现有 API 更加灵活，因为您不必立即修改所有现有应用程序。
3. 封装数据库中的所有数据逻辑。根据我的经验，这是最有问题的，因为它将开发人员与业务逻辑如何工作的知识分开，并且可能是最脆弱的 - 当一个存储过程更改开始破坏其他应用程序时，它可能比另一个应用程序更难检测到方法。

根据我的经验，这取决于团队之间关于如何进行变革的更成熟的流程和协议(protocol)。您确实必须将业务层/数据访问层视为 API，并且在进行更改时非常保守。如果您尚未使用持续构建系统，我强烈推荐它，因为它可以帮助您尽早捕获破坏现有应用程序的更改，并允许您保持同步。