2

我们当前的应用程序在单个 JVM 中运行。

我们现在将应用程序拆分为单独的逻辑服务，每个服务在其自己的 JVM 中运行。

进行拆分是为了允许修改和部署单个服务，而不会影响整个系统。这减少了对整个系统进行 QA 的需要——只需要对与正在更改的服务的交互进行 QA。

对于服务间通信，我们使用 REST、MQ 系统总线和数据库视图的组合。

我不喜欢这个：

  • REST 意味着我们必须将数据编组到/从 XML
  • DB 视图将系统耦合在一起，这破坏了单独服务的整个概念
  • MQ/系统总线增加了复杂性
  • 服务之间不可避免地存在一些代码重复
  • 您已经设置了 n 个 JBoss 服务器配置，我们必须进行 n 次部署、n 次设置脚本等，等等。

是否有更好的方法来构建内部应用程序以允许模块化开发和部署，同时允许应用程序在单个 JVM 中运行（并获得相关的好处）？

4

2 回答 2

3

我对您在这里真正要问的内容感到有些困惑。如果您将应用程序拆分为在网络上运行的不同服务，那么数据编组必须在某处进行。

话虽如此，你调查过OSGi吗？您可以将不同的包（基本上，带有定义接口的附加元数据的 jar 文件）部署到同一个 OSGi 服务器中，并且服务器将透明地促进这些包之间的通信，因为一切都在同一个 JVM 中运行 - 即您在对象上调用方法像往常一样使用不同的捆绑包。

OSGi 服务器将允许在运行时卸载和升级包，并且应用程序应该正常运行（如果以降级的方式），只要OSGi 包生命周期状态得到尊重。

于 2010-03-14T20:58:14.503 回答
0

听起来您的团队有一个手动 QA 流程，真正的问题是自动化回归测试，以便您可以快速、自信地部署新版本。将代码分解为单独的服务器是一种解决方法。

如果您愿意重新启动服务器，那么一种方法可能是将代码编译成单独的 jar 文件，然后通过放入新的 jar 并重新启动来部署模块。这主要是构建代码库的问题，这样就不会出现不良的依赖关系，并且 jar 之间的调用是通过不变的接口进行的。（或者，使用抽象类，这样您就可以添加一个具有默认实现的新方法。）您的构建系统可以帮助确保单独部署的模块只能依赖于公共接口，而其他任何事情都是编译错误。但是请注意，当您交换未针对其进行编译的 jar 时，您的编译器不会帮助您检测不兼容性，因此我不确定这是否真的避免了良好的 QA 流程。

如果您想在不重新启动 JVM 的情况下部署新代码，那么 OSGI 是执行此操作的标准方法。（但我对此知之甚少。）

于 2010-03-14T21:45:07.247 回答