SpringBoot之二：部署Spring Boot应用程序方式

衡量多种部署方式

Spring Boot应用程序有多种构建和运行方式，其中一些你已经使用过了。

在IDE中运行应用程序（涉及Spring ToolSuite或IntelliJ IDEA）。
使用Maven的spring-boot:run或Gradle的bootRun，在命令行里运行。
使用Maven或Gradle生成可运行的JAR文件，随后在命令行中运行。
使用Spring Boot CLI在命令行中运行Groovy脚本。
使用Spring Boot CLI来生成可运行的JAR文件，随后在命令行中运行。

这些选项每一个都适合运行正在开发的应用程序。但是，如果要将应用程序部署到生产环境或其他非开发环境中，又该怎么办呢？虽然这些选项看起来没有一个能将应用部署于非开发环境，但事实上，它们之中只有一个选项不可用于生产环境——在IDE中运行应用显然不可取。可运行的JAR文件和Spring Boot CLI还是可以考虑的，两者还可以很好地将应用程序部署到云环境里。也许你很想知道如何把Spring Boot应用程序部署到一个更加传统的应用服务器环境里，比如 Tomcat、WebSphere或WebLogic。在这些情境中，可执行JAR文件和Groovy代码不适用。针对应用服务器的部署，你需要将应用程序打包成一个WAR文件。实际上，Spring Boot应用程序可以用多种方式打包，详见表8-1。

如你所见，在做终选择时需要考虑目标环境。如果要将应用程序部署到自己数据中心的 Tomcat服务器上，WAR文件就是你的选择。另一方面，如果要部署到Cloud Foundry，可以使用表里列出的各种选项。本章将关注以下选项。

向Java应用服务器里部署WAR文件。
向Cloud Foundry里部署可执行JAR文件。
向Heroku里部署可执行JAR文件（构建过程是由Heroku执行的）。

探索这些场景的时候，我们还要处理一件事。在开发应用程序时我们使用了嵌入式的H2数据库，现在得把它替换成生产环境所需的数据库了。首先，让我们看看如何将阅读列表应用程序构建为WAR文件。这样才能把它部署到Java应用服务器里，比如Tomcat、WebSphere或WebLogic。

部署到应用服务器

到目前为止，阅读列表应用程序每次运行，Web应用程序都通过内嵌在应用里的Tomcat提供服务。情况和传统Java Web应用程序正好相反。不是应用程序部署在Tomcat里，而是Tomcat部署在了应用程序里。归功于Spring Boot的自动配置功能，我们不需要创建web.xml文件或者Servlet初始化类来声明Spring MVC的DispatcherServlet。但如果要将应用程序部署到Java应用服务器里，我们就需要构建WAR文件了。这样应用服务器才能知道如何运行应用程序。那个WAR文件里还需要一个对Servlet进行初始化的东西。

构建WAR文件实际上，构建WAR文件并不困难。如果你使用Gradle来构建应用程序，只需应用WAR插件即可：
apply plugin: 'war' 随后，在build.gradle里用以下war配置替换原来的jar配置：
war { baseName = 'readinglist' version = '0.0.1-SNAPSHOT' } 两者的唯一区别就是 j 换成了w。

如果使用Maven构建项目，获取WAR文件会更容易。只需把<packaging>元素的值从jar 改为war。

<packaging>war</packaging>

这样就能生成WAR文件了。

但如果WAR文件里没有启用Spring MVC DispatcherServlet 的web.xml文件或者Servlet初始化类，这个WAR文件就一无是处。此时就该Spring Boot出马了。它提供的SpringBootServletInitializer是一个支持 Spring Boot的Spring WebApplicationInitializer实现。除了配置Spring的Dispatcher- Servlet，SpringBootServletInitializer还会在Spring应用程序上下文里查找Filter、 Servlet或ServletContextInitializer类型的Bean，把它们绑定到Servlet容器里。要使用SpringBootServletInitializer，只需创建一个子类，覆盖configure()方法来指定Spring配置类。代码清单8-1是ReadingListServletInitializer，也就是我们为阅读列表应用程序写的SpringBootServletInitializer的子类。

package com.dxz.demo;import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.context.web.SpringBootServletInitializer;public class ReadingListServletInitializer extends SpringBootServletInitializer {@Overrideprotected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {return builder.sources(DemoApplication.class);     //指定spring配置
    }}

如你所见，configure()方法传入了一个SpringApplicationBuilder参数，并将其作为结果返回。期间它调用sources()方法注册了一个Spring配置类。本例只注册了一个 Application类。回想一下，这个类既是启动类（带有main()方法），也是一个Spring配置类。
虽然阅读列表应用程序里还有其他Spring配置类，但没有必要在这里把它们全部注册进来。 Application类上添加了@SpringBootApplication注解。这会隐性开启组件扫描，而组件扫描则会发现并应用其他配置类。现在我们可以构建应用程序了。如果使用Gradle，你只需调用build任务即可：
$ gradle build 没问题的话，你可以在build/libs里看到一个名为readinglist-0.0.1-SNAPSHOT.war的文件。对于基于Maven的项目，可以使用package：
$ mvn package 成功构建之后，你可以在target目录里找到WAR文件。剩下的工作就是部署应用程序了。应用服务器不同，部署过程会有所区别，因此请参考应用服务器的部署说明文档。

对于Tomcat而言，可以把WAR文件复制到Tomcat的webapps目录里。如果Tomcat正在运行（要是没有运行，则在下次启动时检测），则会检测到WAR文件，解压并进行安装。假设你没有在部署前重命名WAR文件， Servlet上下文路径会与WAR文件的主文件名相同，在本例中是/demo-0.0.1-SNAPSHOT。用你的浏览器打开http://server:port/demo-0.0.1-SNAPSHOT就能访问应用程序了。

还有一点值得注意：就算我们在构建的是WAR文件，这个文件仍旧可以脱离应用服务器直接运行。如果你没有删除Application里的main()方法，构建过程生成的WAR文件仍可直接运行，一如可执行的JAR文件：

E:\myspace\demo\target>java -jar demo-0.0.1-SNAPSHOT.war