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

Question

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

我找不到关于这个主题的大量连贯或最新信息，但我有一些想法。我会开始

1. 传统的应用服务器方法（Jetty，Tomcat等）
   • 将软件汇编到war个文件中并制作您自己的配置和部署脚本，例如，使用izpack，ant scripts，cargo或类似内容。
     
2. 依赖于集成平台，例如fabric8，servicemix，fuse等。
   • 看起来像一个很好的自以为是的方法。如果还没有使用其中一种，除了锁定之外，将应用程序重新滚动到这种格式需要一些工作。是不是摆脱大框架的趋势？
3. 将应用程序war文件捆绑到ear（企业归档）文件中
   • 需要一个成熟的java EE服务器，例如wildfly，glassfish等。除非需要这样的服务器的功能，否则它会增加很多开销，因为zip-archive可以做什么。
     
4. 虚拟机：Vagrant，Docker等
   • Docker很不错但是在Windows上主机需要在VM中运行。虚拟机（无论是否流浪）会产生性能开销，并且往往依赖于复杂的配置工具，例如puppet或salt。
5. 可运行的罐子，例如Capsule，maven shade plugin，One-JAR。
   • Capsule似乎很棒，它就像一个可执行的自解压zip文件，它也可以运行应用程序。使用嵌入式jetty，可以从一个可执行文件中提供多个传统war文件。

第一个选项一直是我的参考方法，但需要大量的配置，安装脚本，这些脚本在不同的环境（例如，Linux，Windows）上有所不同。

哪些现代替代品使包装和部署更容易？

^{1）想象一下像微服务，RESTful通信等的SOA设置。
2）考虑到这一点，让我们排除诸如cloudbees，cloudfoundy等的PaaS提供商。他们应该得到自己的主题。}

Answer 1

我建议阅读The Twelve-Factor App文档，其灵感来自Martin Fowler的企业应用程序架构模式和重构书籍。它表明了以下内容：

1. 每个应用程序应该有一个codebase（版本控制系统），并且应用程序在不同环境（开发，登台，生产）中进行了多次部署。
应该明确声明和隔离
2. Dependencies（永远不要依赖于系统范围的软件包或系统工具的隐式存在）。
3. Config（部署之间可能存在差异的一切）应该存储在环境中，而不是存储在代码中。
4. Backing services（包括其他应用）应被视为附加资源，通过config中存储的定位符/凭据进行访问。
5. Build, release and run阶段应严格分开。
6. 应用程序应该作为一个或多个无状态和无共享processes执行（状态不应存储在“粘性会话”中，而应存储在提供时间到期的数据存储中）。
7. 该应用应该是完全独立的（通常会向应用添加网络服务器库），通过port binding将HTTP作为服务导出。
8. 由于十二因素应用processes的可分区性质，应通过流程模型简单可靠地添加更多concurrency。
9. 应用应该通过快速启动和正常关机来对待disposability。
10. 开发，登台和生产环境应尽可能相似（Dev/prod parity）。
11. 应用应将logs视为事件流，从不关注其路由或存储。
12. Admin processes应作为一次性流程运行。

还有詹姆斯·刘易斯和马丁福勒的Microservices文章，其中陈述了上面列举的一些想法。

关于打包和部署，后一篇文章建议如下：

1. Componentization via Services

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

2. Organized around Business Capabilities

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

3. Smart endpoints and dumb pipes

   应该使用简单的RESTish协议编排从微服务构建的应用程序。两个最常用的协议是使用资源API的HTTP请求响应，以及通过哑巴（例如RabbitMQ或ZeroMQ）的轻量级消息传递。

4. Infrastructure Automation

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

Answer 2

如果您使用Maven，Tomcat Maven插件的目标是创建可执行JAR以及标准WAR。您可以使用java -jar path_to.jar运行jar。在没有预先存在的Tomcat安装的情况下运行应用程序的有趣方式。看看：http://tomcat.apache.org/maven-plugin-2.2/executable-war-jar.html