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

Question

在异构环境中打包和部署服务器端java软件¹⁾的现代替代方案²⁾？

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

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

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

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

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

Answer 1

我建议阅读The Twelve-Factor App文档,其灵感来自Martin Fowler 的企业应用程序架构模式和重构书籍.它表明如下:

1. 每个应用程序应该有一个代码库(版本控制系统),以及在不同环境(开发,登台,生产)中应用程序的许多部署.
2. 应明确声明和隔离依赖关系(从不依赖于系统范围包或系统工具的隐式存在).
3. 配置(部署之间可能有所不同的一切)应该存储在环境中,而不是存储在代码中.
4. 备份服务(包括其他应用程序)应视为附加资源,通过配置中存储的定位符/凭证进行访问.
5. 构建,发布和运行阶段应严格分开.
6. 应用程序应作为一个或多个无状态和无共享进程执行(状态不应存储在"粘性会话"中,而应存储在提供时间到期的数据存储中).
7. 该应用程序应该是完全独立的(通常是向应用程序添加Web服务器库),通过端口绑定将HTTP作为服务导出.
8. 由于十二因素应用程序进程的可分区性,因此应通过流程模型简单可靠地实现添加更多并发性.
9. 该应用程序应通过实现快速启动和正常关闭来处理可处置性.
10. 开发,登台和生产环境应尽可能相似(开发/生产平价).
11. 应用程序应将日志视为事件流,从不涉及其路由或存储.
12. 管理进程应作为一次性进程运行.

还有的文章微服务由詹姆斯·刘易斯和Martin Fowler的,即规定了一些上面列举的想法.

关于包装和部署,后一篇文章的建议如下:

1. 通过服务进行组件化

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

2. 围绕业务能力进行组织

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

3. 智能端点和哑管

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

4. 基建自动化

   构建,部署和运行微服务的操作复杂性可以通过持续交付的自动化或它的前身,持续集成来减少.