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

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

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

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

我不喜欢这个的地方是:

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

是否有更好的方法来构建内部应用程序以允许模块化开发和部署,同时允许应用程序在单个 JVM 中运行(并实现相关优势)?

有帮助吗?

解决方案

我有点困惑你在这里真正要问的是什么。如果您将应用程序分成跨网络运行的不同服务,则数据编组必须在某个地方进行。

话虽如此,你调查过吗? 操作系统Gi ?您可以部署不同的 捆绑 (基本上,带有定义接口的附加元数据的 jar 文件)到同一个 OSGi 服务器中,并且服务器将透明地促进这些包之间的通信,因为所有内容都在同一个 JVM 中运行 - 即。您可以像平常一样调用不同包中对象的方法。

OSGi 服务器将允许在运行时卸载和升级捆绑包,并且应用程序应该正常运行(如果以降级方式) OSGi 包生命周期 国家受到尊重。

其他提示

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

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

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

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top