java - 打包和部署企业应用程序的现代替代方案？

Question

关闭。这个问题不满足Stack Overflow guidelines .它目前不接受答案。












想改善这个问题吗？更新问题，使其成为 on-topic对于堆栈溢出。

7年前关闭。




Improve this question




在异构环境中打包和部署服务器端 java 软件 1) 2) 的现代替代方案是什么？

我找不到很多关于该主题的连贯或最新信息，但我有一些想法。我会开始

传统的应用服务器方法( Jetty 、 Tomcat 等)

将软件组装成war文件并制作您自己的配置和部署脚本，例如，使用 izpack , ant scripts , cargo或类似的东西。

依赖集成平台，例如，fabric8 , servicemix , fuse ， 等等。

似乎是一个很好的自以为是的方法。如果尚未使用其中之一，除了锁定之外，将应用程序重新滚动到这种格式需要一些工作。远离大型框架的趋势不是吗？

捆绑应用 war文件到 ear (企业文件)文件

需要一个成熟的 Java EE 服务器，例如，wildfly , glassfish等等。除非需要这种服务器的功能，否则它会为 zip-archive 已经可以做的事情增加很多开销。

虚拟机:Vagrant , Docker ， 等等。

Docker 很好，但无论如何都需要在 Windows 主机上运行。虚拟机( Vagrant )会产生性能开销，并且倾向于依赖复杂的配置工具，例如 puppet或 salt .

可运行的 jars，例如，Capsule , maven shade plugin , One-JAR .

Capsule看起来很棒，它就像一个可执行的、自解压的 zip 文件，它也运行应用程序。带有嵌入式 jetty 多个传统war文件可以从一个可执行文件提供。

第一个选项长期以来一直是我的引用方法，但需要大量的配置和安装脚本，这两者在不同的环境(例如 Linux、Windows)上会有所不同。

有哪些现代替代方案可以让打包和部署更容易？

1) 想象一个 SOA 之类的设置，包括微服务、RESTful 通信等。
2) 考虑到这一点，让我们排除 PaaS Cloudbees、cloudfoundy 等提供商。他们应该有自己的主题。

Answer 1

我推荐阅读 The Twelve-Factor App文档，灵感来自 Martin Fowler 的《企业应用程序架构模式和重构》书籍。它提出以下建议:

应该有一个 codebase (版本控制系统)每个应用程序，以及应用程序在不同环境(开发、暂存、生产)中的许多部署。

Dependencies应该明确声明和隔离(永远不要依赖系统范围包或系统工具的隐式存在)。

Config (在部署之间可能会有所不同的所有内容)应该存储在环境中，而不是存储在代码中。

Backing services (包括其他应用程序)应被视为附加资源，通过存储在 config 中的定位器/凭据访问.

Build, release and run各个阶段应该严格分开。

该应用程序应作为一个或多个无状态且无共享的应用程序执行 processes (状态不应存储在“粘性 session ”中，而应存储在提供时间到期的数据存储中)。

应用程序应该是完全独立的(通常向应用程序添加一个网络服务器库)，通过 port binding 将 HTTP 作为服务导出.

由于十二因素应用程序的可分区特性processes , 添加更多 concurrency应该通过过程模型简单可靠地实现。

该应用程序应处理 disposability通过实现快速启动和优雅关闭。

开发、暂存和生产环境应尽可能相似 ( Dev/prod parity )。

该应用程序应处理 logs作为事件流，从不关心它的路由或存储。

Admin processes应该作为一次性过程运行。

还有关于 Microservices 的文章由 James Lewis 和 Martin Fowler 撰写，其中陈述了上面列举的一些想法。

关于打包和部署，后一篇文章的建议是:

Componentization via Services

应用程序(及其微服务)应该作为可以独立替换、升级和部署的进程外组件(而不是进程内库)来实现。组件通过使用显式远程调用机制提供更显式的组件接口(interface)。

Organized around Business Capabilities

每个组件都应围绕业务能力组织，针对特定业务领域，采用软件的道路堆栈实现，包括用户界面、持久存储和任何外部协作。这种方法还允许跨团队项目在同一组件上协同工作(并在其整个生命周期内拥有产品)。

Smart endpoints and dumb pipes

从微服务构建的应用程序应该使用简单的 RESTish 协议(protocol)进行编排。两个最常用的协议(protocol)是带有资源 API 的 HTTP 请求-响应，以及通过哑总线(例如 RabbitMQ 或 ZeroMQ )的轻量级消息传递。

Infrastructure Automation

使用 Continuous Delivery 自动化可以降低构建、部署和操作微服务的操作复杂性或者它的前身，Continuous Integration .