允许在同一 JVM 中运行的同时进行模块化开发吗？
我们当前的应用程序在单个 JVM 中运行。
我们现在将应用程序拆分为单独的逻辑服务，其中每个服务都在自己的 JVM 中运行。
进行拆分是为了允许修改和部署单个服务而不影响整个系统。这减少了对整个系统进行质量检查的需要 - 只需要对与正在更改的服务的交互进行质量检查。
对于服务间通信，我们结合使用 REST、MQ 系统总线和数据库视图。
我不喜欢这一点：
- REST 意味着我们必须将数据编组到 XML
- DB 视图中/从 XML DB 视图中编组数据 将系统耦合在一起，这违背了单独服务的整个概念
- MQ/系统总线增加了复杂性
- 之间不可避免地存在一些代码重复
- 服务 已经设置了 n 个 JBoss 服务器配置，我们必须进行 n 次部署、n 次设置脚本等等。
是否有更好的方法来构建内部应用程序，以允许模块化开发和部署，同时允许应用程序运行在单个 JVM 中（并实现相关的好处）？
Our current app runs in a single JVM.
We are now splitting up the app into separate logical services where each service runs in its own JVM.
The split is being done to allow a single service to be modified and deployed without impacting the entire system. This reduces the need to QA the entire system - just need to QA the interaction with the service being changed.
For inter service communication we use a combination of REST, an MQ system bus, and database views.
What I don't like about this:
- REST means we have to marshal data to/from XML
- DB views couple the systems together which defeats the whole concept of separate services
- MQ / system bus is added complexity
- There is inevitably some code duplication between services
- You have set up n JBoss server configurations, we have to do n number of deployments, n number of set up scripts, etc, etc.
Is there a better way to structure an internal application to allow modular development and deployment while allowing the app to run in a single JVM (and achieving the associated benefits)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我有点困惑你在这里真正要问的是什么。如果您将应用程序分成跨网络运行的不同服务，则数据编组必须在某个地方进行。
话虽如此，您是否调查过 OSGi ？您可以部署不同的捆绑包（基本上，包含定义接口的附加元数据的 jar 文件）到同一个 OSGi 服务器中，并且服务器将透明地促进这些包之间的通信，因为所有内容都在同一个 JVM 中运行 - 即，您可以像平常一样调用不同包中对象的方法。
OSGi 服务器将允许在运行时卸载和升级包，并且应用程序应该正常运行（如果以降级方式），前提是 OSGi 包生命周期 状态受到尊重。
I'm a little confused as to what you're really asking here. If you split your application up into different services running across the network, then data marshalling has to occur somewhere.
Having said that, have you investigated OSGi ? You can deploy different bundles (basically, jar files with additional metadata defining the interfaces) into the same OSGi server, and the server will facilitate communication between these bundles transparently, since everything is running within the same JVM - i.e. you call methods on objects in different bundles as you would normally.
An OSGi server will permit unloading and upgrades of bundles at runtime and applications should run normally (if in a degraded fashion) provided the OSGi bundle lifecycle states are respected.
听起来您的团队有一个手动 QA 流程，真正的问题是自动化回归测试，以便您可以快速、自信地部署新版本。将代码分解到单独的服务器中是一种解决方法。
如果您愿意重新启动服务器，那么一种方法可能是将代码编译到单独的 jar 文件中，然后通过放入新的 jar 并重新启动来部署模块。这主要是构建代码库的问题，这样不良的依赖关系就不会蔓延，并且 jar 之间的调用是通过不改变的接口进行的。 （或者，使用抽象类，这样您就可以添加具有默认实现的新方法。）您的构建系统可以通过确保单独部署的模块只能依赖于公共接口而提供帮助，而其他任何内容都是编译错误。但请注意，当您交换未编译的 jar 时，您的编译器不会帮助您检测不兼容性，因此我不确定这是否真的避免了良好的 QA 过程。
如果您想在不重新启动 JVM 的情况下部署新代码，那么 OSGI 是执行此操作的标准方法。 （但我对此知之甚少。）
It sounds like your team has a manual QA process and the real issue is automating regression tests so that you can deploy new releases quickly and with confidence. Breaking up the code into separate servers is a workaround for that.
If you're willing to restart the server then one approach might be to compile the code into separate jar files, and deploy a module by dropping in a new jar and restarting. This is largely a matter of structuring your code base so that bad dependencies don't creep in and the calls between jars are made via interfaces that don't change. (Or alternately, use abstract classes so you can add a new method with a default implementation.) Your build system could help by making sure that separately deployed modules can only depend on common interfaces and anything else is a compile error. But note that your compiler isn't going to help you detect incompatibilities when you're swapping in jars that you didn't compile against, so I'm not sure this really avoids having a good QA process.
If you want to deploy new code without restarting the JVM then OSGI is the standard way to do that. (But one that I know little about.)