Spring Boot开发指南_springboot开发手册

目录

1. 构建系统

1.1. 依赖管理

1.2. Maven

Maven项目结构

1.3. Starter

2. 代码结构

2.1. “default” 包

2.2. 启动类的位置

3. Configuration 类

3.1. 导入额外的 Configuration 类

3.2. 导入 XML Configuration

4. 自动装配（配置）

4.1. 逐步取代自动配置

4.2. 禁用指定的自动装配类

5. Spring Bean 和 依赖注入

6. 使用 @SpringBootApplication 注解

7. 运行你的应用

7.1. 在IDE中运行应用

7.2. 运行打包后的应用

7.3. 使用 Maven 插件

7.4. 使用 Gradle 插件

7.5. 热部署（Hot Swapping）

8. 开发者工具（Developer Tools）

8.1. 诊断类加载问题

8.2. 属性的默认值

8.3. 自动重启

8.3.1. 记录条件评估的变化

8.3.2. 排除资源

8.3.3. 监控额外的路径

8.3.4. 禁止重启

8.3.5. 使用 trigger file

8.3.6. 自定义重启类加载器（Restart Classloader）

8.3.7. 已知的限制

8.4. LiveReload

8.5. 全局设置

8.5.1. 配置文件系统的监控

8.6. 远程应用

8.6.1. 运行远程客户端程序

8.6.2. 远程更新

9. 打包应用，部署到生产环境

1. 构建系统

强烈建议你选择一个支持依赖管理的构建系统，并且它可以从 “Maven Central” 拉取依赖。我们建议你选择Maven或Gradle。选择其他构建系统（例如Ant），也不是不行，但它们的支持并不特别好。

1.1. 依赖管理

Spring Boot的每个版本都提供了一个它所支持的依赖的列表。 在实践中，你不需要在构建配置中为这些依赖声明版本，因为Spring Boot会帮你管理这些。 当你升级Spring Boot本身时，这些依赖也会一同升级。

你仍然可以指定某个依赖的版本，来覆盖spring boot默认的版本。

这份精心策划依赖清单包含了所有可以在Spring Boot中使用的Spring模块，以及一份第三方库的列表。该列表以依赖（ spring-boot-dependencies ）的形式提供，可在Maven和Gradle中使用。

Spring Boot的每个版本都与Spring框架的基本版本有关。 我们 强烈建议 你不要修改Spring的版本。

1.2. Maven

Maven就是是专门为Java项目打造的管理和构建工具，它的主要功能有：

• 提供了一套标准化的项目结构；
• 提供了一套标准化的构建流程（编译，测试，打包，发布……）；
• 提供了一套依赖管理机制。

Maven项目结构

一个使用Maven管理的普通的Java项目，它的目录结构默认如下：

a-maven-project
├── pom.xml
├── src
│   ├── main
│   │   ├── java
│   │   └── resources
│   └── test
│       ├── java
│       └── resources
└── target

项目的根目录a-maven-project是项目名，它有一个项目描述文件pom.xml，存放Java源码的目录是src/main/java，存放资源文件的目录是src/main/resources，存放测试源码的目录是src/test/java，存放测试资源的目录是src/test/resources，最后，所有编译、打包生成的文件都放在target目录里。这些就是一个Maven项目的标准目录结构。

所有的目录结构都是约定好的标准结构，我们千万不要随意修改目录结构。使用标准结构不需要做任何配置，Maven就可以正常使用。

1.3. Starter

Starter是一系列开箱即用的依赖，你可以在你的应用程序中导入它们。 通过你Starter，可以获得所有你需要的Spring和相关技术的一站式服务，免去了需要到处大量复制粘贴依赖的烦恼。 例如，如果你想开始使用Spring和JPA进行数据库访问，那么可以直接在你的项目中导入 spring-boot-starter-data-jpa 依赖。

Starter含了很多你需要的依赖，以使项目快速启动和运行，并拥有一套一致的、受支持的可管理的过渡性依赖。

关于Starter的命名

所有官方的Starter都遵循一个类似的命名模式；spring-boot-starter-*，其中 * 是一个特定类型的应用程序。 这种命名结构是为了在你需要寻找Starter时提供帮助。 许多IDE中集成的Maven可以让你按名称搜索依赖。 例如，如果安装了相应的Eclipse或Spring Tools插件，你可以在POM编辑器中按下 ctrl-space ，然后输入 “spring-boot-starter” 来获取完整的列表。

正如 “创建你自己的 Starter” 一节所解释的，第三方启动器不应该以 spring-boot 开头，因为它是留给Spring Boot官方组件的。 相反，第三方启动器通常以项目的名称开始。 例如，一个名为 thirdpartyproject 的第三方启动器项目通常被命名为 thirdpartyproject-spring-boot-starter。

以下是Spring Boot在 org.springframework.boot 这个 groupId 下提供的starter组件。

除了应用starter外，以下启动器可用于添加 生产就绪 功能。

最后，Spring Boot还包括以下starter，如果你想排除或更换特定的技术实现，那么可以使用它们。

2. 代码结构

Spring Boot对代码的布局，没有特别的要求。 但是，有一些最佳实践。

2.1. “default” 包

当一个类不包括 package 的声明时，它被认为是在 “default package” 中。 通常应避免使 “default package”。 对于使用了 @ComponentScan, @ConfigurationPropertiesScan, @EntityScan 或者 @SpringBootApplication 注解的Spring Boot应用程序来说，它可能会造成一个问题：项目中的所有jar里面的所有class都会被读取（扫描）。

我们建议你遵循Java推荐的包的命名惯例，使用域名反转作为包名（例如， com.example.project）。

2.2. 启动类的位置

我们通常建议你将你启动类放在一个根package中，高于其他的类，@SpringBootApplication 注解一般都是注解在启动类上的。它默认会扫描当前类下的所有子包。例如，如果你正在编写一个JPA应用程序，你的 @Entity 类只有定义在启动类的子包下才能被扫描加载到。这样的好处也显而易见，@SpringBootApplication 默认只会扫描加载你项目工程中的组件。

如果你不想使用 @SpringBootApplication ，它所导入的 @EnableAutoConfiguration 和 @ComponentScan 注解定义了该行为，所以你也可以使用这些来代替。

一个项目典型的布局如下。

com
 +- example
     +- myapplication
         +- MyApplication.java
         |
         +- customer
         |   +- Customer.java
         |   +- CustomerController.java
         |   +- CustomerService.java
         |   +- CustomerRepository.java
         |
         +- order
             +- Order.java
             +- OrderController.java
             +- OrderService.java
             +- OrderRepository.java

MyApplication.java 文件声明了 main 方法，以及标识了基本的 @SpringBootApplication 注解，如下所示。

Java

@SpringBootApplication
public class MyApplication {
 
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
 
}

3. Configuration 类

Spring Boot倾向于通过Java代码来进行配置的定义。 虽然也可以使用XML来配置 SpringApplication ，但还是建议你通过 @Configuration 类来进行配置。 通常，可以把启动类是作为主要的 @Configuration 类。

网上有很多关于“通过XML配置Spring”的示例，如果可以的话，还是尽量使用Java代码的方式来实现相同的配置。你可以尝试着搜索 Enable* 注解。

3.1. 导入额外的 Configuration 类

你不需要把所有的 @Configuration 放在一个类中。 @Import 注解可以用来导入额外的配置类。 另外，你可以使用 @ComponentScan 来自动扫描加载所有Spring组件，包括 @Configuration 类。

3.2. 导入 XML Configuration

如果你确实需要使用基于XML的配置，我们建议你仍然从 @Configuration 类开始，然后通过 @ImportResource 注解来加载XML配置文件。

4. 自动装配（配置）

Spring Boot的自动装配机制会试图根据你所添加的依赖来自动配置你的Spring应用程序。 例如，如果你添加了 HSQLDB 依赖，而且你没有手动配置任何DataSource Bean，那么Spring Boot就会自动配置内存数据库。

你需要将 @EnableAutoConfiguration 或 @SpringBootApplication 注解添加到你的 @Configuration 类中，从而开启自动配置功能。

你应该只添加一个 @SpringBootApplication 或 @EnableAutoConfiguration 注解。 建议添加到主要的 @Configuration 类上。

4.1. 逐步取代自动配置

自动配置是非侵入性的。 在任何时候，你都可以开始定义你自己的配置来取代自动配置的特定部分。 例如，如果你添加了你自己的 DataSource bean，默认的嵌入式数据库支持就会“退步”从而让你的自定义配置生效。

如果你想知道在应用中使用了哪些自动配置，你可以在启动命令后添加 --debug 参数。 这个参数会为核心的logger开启debug级别的日志，会在控制台输出自动装配项目以及触发自动装配的条件。

4.2. 禁用指定的自动装配类

如果你想禁用掉项目中某些自动装配类，你可以在 @SpringBootApplication 注解的 exclude 属性中指定，如下例所示。

Java

@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })
public class MyApplication {
 
}

如果要禁用的自动装配类不在classpath上（没有导入），那么你可以在注解的 excludeName 属性中指定类的全路径名称。 exclude 和 excludeName 属性在 @EnableAutoConfiguration 中也可以使用。 最后，你也可以在配置文件中通过 spring.autoconfigure.exclude[] 配置来定义要禁用的自动配置类列表。

你可以同时使用注解 + 配置的方式来禁用自动装配类。

5. Spring Bean 和 依赖注入

你可以使用任何标准的Spring技术来定义你的Bean以及依赖注入关系。 推荐使用构造函数注入，并使用 @ComponentScan 注解来扫描Bean。

如果你按照上面的建议构造你的代码（将你的启动类定位在顶级包中），你可以在启动类添加 @ComponentScan 注解，也不需要定义它任何参数， 你的所有应用组件（@Component、@Service、@Repository、@Controller 和其他）都会自动注册为Spring Bean。

也可以直接使用 @SpringBootApplication 注解（该注解已经包含了 @ComponentScan）。

下面的例子展示了一个 @Service Bean，它使用构造器注入的方式注入了 RiskAssessor Bean。

Java

@Service
public class MyAccountService implements AccountService {
 
    private final RiskAssessor riskAssessor;
 
    public MyAccountService(RiskAssessor riskAssessor) {
        this.riskAssessor = riskAssessor;
    }
 
    // ...
 
}

如果一个Bean有多个构造函数，你需要用 @Autowired 注解来告诉Spring该用哪个构造函数进行注入。

Java

@Service
public class MyAccountService implements AccountService {
 
    private final RiskAssessor riskAssessor;
 
    private final PrintStream out;
 
    @Autowired
    public MyAccountService(RiskAssessor riskAssessor) {
        this.riskAssessor = riskAssessor;
        this.out = System.out;
    }
 
    public MyAccountService(RiskAssessor riskAssessor, PrintStream out) {
        this.riskAssessor = riskAssessor;
        this.out = out;
    }
 
    // ...
 
}

6. 使用 @SpringBootApplication 注解

许多Spring Boot开发者希望他们的应用程序能够使用自动配置、组件扫描，并且能够在他们的 "application class "上定义额外的配置。 一个 @SpringBootApplication 注解就可以用来启用这三个功能，如下。

• @EnableAutoConfiguration：启用Spring Boot的自动配置机制。
• @ComponentScan：对应用程序所在的包启用 @Component 扫描（见最佳实践）。
• @SpringBootConfiguration：允许在Context中注册额外的Bean或导入额外的配置类。这是Spring标准的 @Configuration 的替代方案，有助于在你的集成测试中检测配置。

Java

// Same as @SpringBootConfiguration @EnableAutoConfiguration @ComponentScan
@SpringBootApplication
public class MyApplication {
 
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
 
}

@SpringBootConfiguration(proxyBeanMethods = false)
@EnableAutoConfiguration
@Import({ SomeConfiguration.class, AnotherConfiguration.class })
public class MyApplication {
 
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
 
}

7. 运行你的应用

把应用打包成可执行jar，并且使用嵌入式HTTP服务器的最大优势，就是可以像其他程序一样运行应用。

该样本适用于调试Spring Boot应用程序。 你不需要任何特殊的IDE插件或扩展。

7.1. 在IDE中运行应用

你可以在IDE中像运行普通Java程序一样运行你的Spring Boot应用。 不过，你首先需要导入你的项目。 不同的IDE导入方式可能不同， 大多数IDE可以直接导入Maven项目。 例如，Eclipse用户可以从 File 菜单中选择 Import…​ → Existing Maven Projects 。

如果你不能直接将项目导入IDE，你可以通过构建插件来生成IDE的元数据。包括用于 Eclipse 和 IDEA 的 Maven 插件。Gradle为各种 IDE 都提供了插件。

7.2. 运行打包后的应用

如果你使用Spring Boot的Maven或Gradle插件来创建可执行jar，你可以使用 java -jar 来运行你的打包后应用程序，如下例所示。

$ java -jar target/myapplication-0.0.1-SNAPSHOT.jar

打包后的jar程序，也支持通过命令行参数开启远程调试服务，如下。

$ java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=8000,suspend=n \
       -jar target/myapplication-0.0.1-SNAPSHOT.jar

7.3. 使用 Maven 插件

Spring Boot Maven 插件包括一个 run 目标（goal），可用于快速编译和运行你的应用程序。 应用程序以 exploded 的形式运行，就像在IDE中一样。 运行Spring Boot应用的Maven命令如下。

$ mvn spring-boot:run

如果项目的构建需要消耗很大的内存，你可以考虑使用 MAVEN_OPTS 环境变量来修改最大内存，参考如下。

$ export MAVEN_OPTS=-Xmx1024m

7.4. 使用 Gradle 插件

Spring Boot Gradle插件还包括一个 bootRun 任务，可以用来以 exploded 的形式运行你的应用程序。 只要你应用了了 org.springframework.boot 和 java 插件，就会添加 bootRun 任务，如下例所示。

$ gradle bootRun

同上，如果Gradle构建项目出现内存不足，可以通过 JAVA_OPTS 环境变量来增加JVM的内存。

$ export JAVA_OPTS=-Xmx1024m

7.5. 热部署（Hot Swapping）

由于Spring Boot应用程序是普通的Java应用程序，JVM的热替换功能可以直接使用。但是，JVM的热替换能替换的字节码有限。要想获得更完整的解决方案，可以使用 JRebel 。

spring-boot-devtools 模块提供了快速重启应用程序的支持。详情请见 热部署 “How-to”

8. 开发者工具（Developer Tools）

Spring Boot 提供了一套额外的工具，可以让你更加愉快的开发应用。 spring-boot-devtools 模块可以包含在任何项目中，以在开发期间提供一些有用的特性。 要使用devtools，请添加以下依赖到项目中。

Maven

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-devtools</artifactId>
        <optional>true</optional>
    </dependency>
</dependencies>

Gradle

dependencies {
    developmentOnly("org.springframework.boot:spring-boot-devtools")
}

8.1. 诊断类加载问题

如 重启 Vs 重载 一节所述，重启功能是通过使用两个classloader实现的。 对于大多数应用程序来说，这种方法效果很好。 然而，它有时会导致类加载问题，特别是在多模块项目中。

为了诊断类加载问题是否确实是由devtools和它的两个类加载器引起的，请试着禁用 restart。如果这能解决你的问题，请定制 restart 类加载器 以包括你的整个项目。

8.2. 属性的默认值

在Spring Boot支持的一些库中，会使用缓存来提高性能。例如，模板引擎会缓存已编译的模板，以避免重复解析模板文件。另外，Spring MVC可以在响应静态资源时往响应中添加HTTP缓存头。

虽然缓存在生产中是非常有益的，但在开发过程中可能会产生反作用，使你无法看到你在应用程序中刚做的改动。 由于这个原因，spring-boot-devtools 默认禁用了缓存选项。

缓存的选项通常是通过 application.properties 文件中的属性来配置的。 例如，Thymeleaf提供了 spring.thymeleaf.cache[] 属性。 与其需要手动设置这些属性，spring-boot-devtools 模块会在开发场景下合理的设置这些属性。

下表列出了所有被设置的属性。

在开发Spring MVC和Spring WebFlux应用程序时，你可能需要更多关于Web请求的信息，开发者工具建议你为Web日志组启用DEBUG日志。这将给你提供关于客户端的请求信息，哪个handler正在处理它，响应结果，以及其他细节。如果你希望记录所有的请求细节（包括潜在的敏感信息），你可以打开 spring.mvc.log-request-details[] 或 spring.codec.log-request-details[] 配置。

8.3. 自动重启

使用spring-boot-devtools的应用程序会在classpath上的文件发生变化时自动重启。当在IDE中工作时，这可能是一个有用的功能，因为它为代码变化提供了一个非常快速的反馈。默认情况下，classpath上任何指向目录的条目都会被监测到变化。注意，某些资源，如静态资源和视图模板发生变化时，不需要重启应用程序。

触发重启

由于DevTools监控classpath资源，触发重启的唯一方法是更新classpath。 无论你使用的是IDE还是构建插件，被修改的文件都必须被重新编译以触发重启。 导致更新classpath的方式取决于你所使用的工具。

• 在Eclipse中，保存一个修改过的文件会导致classpath被更新并触发重启。
• 在IntelliJ IDEA中，构建项目（ Build +→+ Build Project ）有同样的效果。
• 如果使用构建插件，运行Maven的 mvn compile 或Gradle的 gradle build 会触发重启。

重启 vs 重载

Spring Boot通过两个类加载器实现了重启。 不变的类（例如，来自第三方jar的类）被加载到一个 base classloader。 你正在开发的类被加载到 restart classloader中。 当应用程序被重新启动时， restart classloader 被丢弃，并被创建一个新的。 这种方法意味着应用程序的重启通常比 “冷启动” 快得多，因为 base classloader 已经可用并被填充。

如果你发现重启对你的应用程序来说不够快，或者你遇到了类加载相关的问题，你可以考虑重载技术，如ZeroTurnaround的 JRebel。这些技术的工作原理是在类被加载时对其进行重写，使其更容易被重载。

8.3.1. 记录条件评估的变化

默认情况下，每次你的应用程序重新启动时，都会记录一份显示条件评估delta的报告。 该报告显示了你的应用程序的自动配置的变化，因为你做了一些改变，如添加或删除Bean和设置配置属性。

要禁用报告的记录，请设置以下属性。

Properties

Yaml

spring.devtools.restart.log-condition-evaluation-delta=false

8.3.2. 排除资源

某些资源在被改变时不一定需要触发重启。例如，Thymeleaf模板可以就地编辑。默认情况下，改变 /META-INF/maven, /META-INF/resources, /resources, /static, /public, /templates 中的资源不会触发重启，但会触发实时重载.。如果你想自定义这些排除项，可以使用 spring.devtools.restart.exclude 属性。例如，要只排除 /static 和 /public ，你可以设置以下属性。

Properties

Yaml

spring.devtools.restart.exclude=static/**,public/**

8.3.3. 监控额外的路径

当你对不在classpath上的文件进行修改时，你可能希望你的应用程序被重新启动或重新加载。为此，使用 spring.devtools.restart.extra-paths 属性来配置监控变化的额外路径。你可以使用前面说过的的 spring.devtools.restart.exclude 属性来控制额外路径下的变化是触发完全重启还是实时重载。

8.3.4. 禁止重启

如果你不想使用重启功能，你可以通过使用 spring.devtools.restart.enabled 属性来禁用它。在大多数情况下，你可以在你的 application.properties 中设置这个属性（这样做仍然会初始化restart 类加载器，但它不会监控文件变化）。

如果你需要完全禁用重启支持（例如，因为它不能与特定的库一起工作），你需要在调用 SpringApplication.run(…​) 之前将 spring.devtools.restart.enabled 属性设置为 false ，如下面的例子中所示。

Java

@SpringBootApplication
public class MyApplication {
 
    public static void main(String[] args) {
        System.setProperty("spring.devtools.restart.enabled", "false");
        SpringApplication.run(MyApplication.class, args);
    }
 
}

8.3.5. 使用 trigger file

如果你只想在在特定时间触发重启，你可以使用 “trigger file”，这是一个特殊的文件，当你想实际触发重启检查时，那你就对这个文件进行修改。

通过属性 spring.devtools.restart.trigger-file 设置trigger file 文件的名称（不包括任何路径）。 trigger file必须在classpath路径上。

例如，如果你有一个结构如下的项目。

src
+- main
   +- resources
      +- .reloadtrigger

那么你的 “trigger-file” 属性应该设置为如下。

Yaml

spring:
  devtools:
    restart:
      trigger-file: ".reloadtrigger"

现在只有当 src/main/resources/.reloadtrigger 被更新时才会重新启动。

有些IDE有一些功能，使你不需要手动更新你的触发器文件。 Spring Tools for Eclipse 和 IntelliJ IDEA (Ultimate Edition)）都有这种支持。对于Spring Tools，你可以使用控制台视图中的 “reload” 按钮（需要把你的 trigger-file 命名为 .reloadtrigger）。对于IntelliJ IDEA，你可以按照其文档中的说明进行操作。

8.3.6. 自定义重启类加载器（Restart Classloader）

正如前面在"Restart vs Reload"所描述的，重启功能是通过使用两个classloader实现的。如果这导致了其他的问题，你可能需要自定义类加载器。

默认情况下，你的IDE中任何打开的项目都是用 “restart” 类加载器加载的，而任何常规的 .jar 文件都是用 “base” 类加载器加载。 如果你使用 mvn spring-boot:run 或 gradle bootRun 也是一样：包含了 @SpringBootApplication 的项目用 “restart” 类加载器加载，其他都用 “base” 类加载器。

你可以通过创建 META-INF/spring-devtools.properties 文件来指定Spring Boot用不同的类加载器来加载你的项目的不同部分。 spring-devtools.properties 文件可以包含以 restart.exclude 和 restart.include 开头的属性。 include 元素是应该被“拉”到 “restart” 类加载器中的项目，而 exclude 元素是应该被“推”到 “base” 类加载器中的项目。 该属性的值是一个基于classpath的正则表达式，如以下例子所示。

Yaml

restart:
  exclude:
    companycommonlibs: "/mycorp-common-[\\w\\d-\\.]+\\.jar"
  include:
    projectcommon: "/mycorp-myproj-[\\w\\d-\\.]+\\.jar"

8.3.7. 已知的限制

如果你使用标准的 ObjectInputStream 来反序列化对象，那么重启功能的效果可能并不好。 如果你需要反序列化数据，你可能需要使用到Spring的 ConfigurableObjectInputStream 与 Thread.currentThread().getContextClassLoader()。

不幸的是，一些第三方库在反序列化时没有考虑到上下文的类加载器。 如果你发现这样的问题，你需要向原作者请求修复。

8.4. LiveReload

spring-boot-devtools 模块包括一个内嵌的LiveReload服务器，可以用来在资源发生变化时触发浏览器刷新。LiveReload浏览器扩展可以从 livereload.com免费获得，支持Chrome、Firefox和Safari。

如果你不想在应用程序运行时启动LiveReload服务器，你可以将 spring.devtools.livereload.enabled 属性设置为 false 。

8.5. 全局设置

你可以通过在 $HOME/.config/spring-boot 目录下添加以下任何文件来配置全局的devtools设置。

1. spring-boot-devtools.properties
2. spring-boot-devtools.yaml
3. spring-boot-devtools.yml

添加到这些文件中的任何属性都适用于你机器上使用devtools的 所有 Spring Boot应用程序。 例如，如果要将重启配置为总是使用trigger file，你可以在 spring-boot-devtools 文件中添加以下属性。

Yaml

spring:
  devtools:
    restart:
      trigger-file: ".reloadtrigger"

默认情况下，$HOME 是用户的主目录。 要自定义这个位置，请设置 SPRING_DEVTOOLS_HOME 环境变量或 spring.devtools.home 系统属性。

8.5.1. 配置文件系统的监控

FileSystemWatcher 的工作方式是以一定的时间间隔轮询类的变化，然后等待一个预定义的安静期，以确保不再有变化。 由于Spring Boot完全依赖IDE来编译并将文件复制到Spring Boot可以读取的位置，你可能会发现有时devtools重新启动应用程序时，某些变化并没有反映出来（没有立即生效）。 如果你经常观察到这样的问题，可以尝试增加 spring.devtools.restart.poll-interval 和 spring.devtools.restart.quiet-period 参数到适合你开发环境的值。

Yaml

spring:
  devtools:
    restart:
      poll-interval: "2s"
      quiet-period: "1s"

受监控的classpath目录现在每2秒轮询一次变化，并保持1秒的安静期以确保没有额外的类变化。

8.6. 远程应用

Spring Boot的开发者工具并不局限于本地开发。 你也可以在远程运行应用程序时使用一些功能。 远程支持是可选的，因为启用它可能会有安全风险。 只有在受信任的网络上运行时，或在用SSL保护时，才应启用它。 如果这两个选项对你来说都不可用，你就不应该使用DevTools的远程支持。 你更不应该在生产环境中启用它。

要启用它，你需要确保 devtools 包含在重新打包的归档文件（jar）中，如以下所示。

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <excludeDevtools>false</excludeDevtools>
            </configuration>
        </plugin>
    </plugins>
</build>

然后你需要设置 spring.devtools.remote.secret 属性。 就像任何重要的密码或密钥一样，这个值应该是唯一的和足够强大的，以至于它不能被猜到或被暴力破解。

Remote devtools support is provided in two parts: a server-side endpoint that accepts connections and a client application that you run in your IDE. The server component is automatically enabled when the spring.devtools.remote.secret property is set. The client component must be launched manually.

远程devtools支持由两部分组成：一个接受连接的服务器端端点和一个你在IDE中运行的客户端应用程序。 当 spring.devtools.remote.secret 属性被设置时，服务器组件会自动启用。 客户端组件必须手动启动。

8.6.1. 运行远程客户端程序

远程客户端应用程序被设计成可以在你的IDE中运行。 你需要运行 org.springframework.boot.devtools.RemoteSpringApplication ，其classpath与你所连接的远程项目相同。 该应用程序的唯一必要参数是它所连接的远程URL。

例如，如果你使用的是 Eclipse 或 Spring Tools，并且你有一个名为 my-app 的项目，并已将其部署到 Cloud Foundry，你可以执行以下操作。

• 从 Run 菜单中选择 Run Configurations…​。
• 创建一个新的 Java Application “launch configuration”。
• 浏览 my-app 项目。
• 使用 org.springframework.boot.devtools.RemoteSpringApplication 作为main类。
• 在 Program arguments 中添加 https://myapp.cfapps.io（或者你的远程URL）。

一个正在运行的远程客户端可能类似于如下。

  .   ____          _                                              __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _          ___               _      \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` |        | _ \___ _ __  ___| |_ ___ \ \ \ \
 \\/  ___)| |_)| | | | | || (_| []::::::[]   / -_) '  \/ _ \  _/ -_) ) ) ) )
  '  |____| .__|_| |_|_| |_\__, |        |_|_\___|_|_|_\___/\__\___|/ / / /
 =========|_|==============|___/===================================/_/_/_/
 :: Spring Boot Remote ::  (v3.2.0-SNAPSHOT)
 
2023-06-26T13:23:55.928+08:00  INFO 12660 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Starting RemoteSpringApplication v3.2.0-SNAPSHOT using Java 17 with PID 12660 (/Users/myuser/.m2/repository/org/springframework/boot/spring-boot-devtools/3.2.0-SNAPSHOT/spring-boot-devtools-3.2.0-SNAPSHOT.jar started by myuser in /opt/apps/)
2023-06-26T13:23:55.935+08:00  INFO 12660 --- [           main] o.s.b.devtools.RemoteSpringApplication   : No active profile set, falling back to 1 default profile: "default"
2023-06-26T13:23:56.300+08:00  INFO 12660 --- [           main] o.s.b.d.a.OptionalLiveReloadServer       : LiveReload server is running on port 35729
2023-06-26T13:23:56.333+08:00  INFO 12660 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Started RemoteSpringApplication in 0.978 seconds (process running for 1.753)

8.6.2. 远程更新

远程客户端以与本地 restart相同的方式监控你的应用程序classpath的变化。任何更新的资源都会被推送到远程应用程序，并（如果需要）触发重启。如果你在一个云服务上进行功能迭代，而你在本地没有云服务，这可能会很有帮助。一般来说，远程更新和重启要比完整的重建和部署周期快得多。

在一个较慢的开发环境中，可能会发生“等待时间”不够的情况，类的变化可能被分成几批。 在第一批类的变化被上传后，服务器被重新启动。 下一批则不能被发送到应用程序，因为服务器正在重启。

这通常表现为 RemoteSpringApplication 日志中的警告，即未能上传一些类，并随之重试。 但它也可能导致应用程序代码不一致，以及在第一批修改上传后无法重新启动。 如果你经常观察到这样的问题，可以尝试增加 spring.devtools.restart.poll-interval 和 spring.devtools.restart.quiet-period 参数到适合你开发环境的值。 参见"配置文件系统监听器"一节，以配置这些属性。

9. 打包应用，部署到生产环境

可执行jar可以用于生产环境，由于它们是独立的，非常适合部署到云服务中。