使用虚拟化基础架构进行Java EE应用程序分发 - 可行的替代方案？

Question

我们公司构建定制的Java EE网络解决方案。目前，我们使用标准的Java EE分发机制（ear/war档案）。 应用程序服务器通常由我们客户的IT部门管理，由于我们无法完全控制环境，因此可以在解决方案中引入大量的熵。例如：

• 最新的应用程序。服务器的补丁没有应用
• 冲突的内部应用程序的第三方库。服务器根
• 服务器运行和调节参数没有配置（例如，在数据库池连接数）

，我们也在考虑使用虚拟化基础架构的Java EE应用程序分发。我们不会发送ear/war归档文件，而是预先发送应用程序服务器节点和我们的应用程序的映像。 一些好处与通常使用虚拟化基础架构相同，即更好地使用硬件资源。对我们来说，它减少了托管基础架构的熵 - 分布式虚拟机应该受托管环境的影响较小。

到目前为止，我看到的缺点可以在应用程序服务器的许可证，在这里，他们将不得不使用专用服务器为我们的解决方案，但是这通常是已经完成的方式。此外，维护虚拟化基础架构也很复杂，但与管理和微调Java EE解决方案相比，IT部门往往拥有更多的经验。

任何人有这种模式的经验吗？有什么缺点？ 我们不只是将其中一种复杂性替换为其他类型的复杂性？

Answer 1

，我们就不会只是与其他替代一种类型的复杂性？

我觉得这样确实如此。首先，虚拟化基础架构仍然需要维护。其次（这是恕我直言最重要的变化），you将成为应用程序和运行时（容器）的负责人。换句话说，这意味着外包的剥削。作为客户和服务提供者，我都不会喜欢这样，特别是没有一个强有力的合同来定义规则，边界和条件等，以避免任何责任战争。这听起来很复杂，而且这似乎不是您客户选择的路径。

---

更新：接听来自OP

（...）在我们的经验，评论，客户往往有基础设施，配置和管理方面的问题，并最终他们默认给我们。我们的合作伙伴（应用服务器供应商）在这个意义上都没有证明有帮助。最后，我们的团队必须进行客户端安装并帮助进行配置，调整和安装。我觉得虚拟化模式将提供更清晰的问题分离。

你所描述经常也发生在我的经验，我知道你在说什么，但仍，红外问题默认为你的即使分辨率，你对他们不负责，这是一个巨大的区别。我在这里没有推广CYA战略，我有一个根本性的区别：如果你开始提供基础设施服务，如果服务器停机并且你的客户没有钱，会发生什么？这将是你的故障。因此，虽然虚拟化模式确实可以提供更清晰的关注点分离，但这会对您的公司需要考虑的严重非技术含义（法律，财务）产生影响。