Spring Boot 2.3.0发布：聚焦云技术

Spring Boot发布了2.3.0版本，添加了对buildpacks方式的Docker、分层镜像、优雅关机、存活性（liveness）和就绪性（readiness）探针的支持。另外一个值得关注的变化就是它支持Java 14，同时保持了对Java LTS版本8和11的支持。

Buildpacks是Dockerfiles的一个替代方案。Buildpacks能够自动探测运行Docker容器中的应用时所需要的软件。例如，它会探测应用中所使用的Java版本。基于该版本，buildpack会选择所指定的JRE并构建Docker镜像。借助Maven或Gradle，可以通过如下的命令创建Docker镜像：

spring-boot:build-image

注意，创建基于buildpacks的Docker镜像不需要任何配置。

通过使用bootBuildImage task，我们可以修改buildpack的一些配置。例如，构建文件中如下的Spring Boot Maven Plugin配置展示了如何修改Docker镜像的名称：

<configuration>
    <image>
        <name>infoq.com/${project.artifactId}:${project.version}</name>
    </image>
</configuration>

我们还可以通过命令行来指定Docker镜像的名称：

mvn/gradle bootBuildImage --imageName=infoq.com/my-app:v1

Docker镜像是以分层的形式运行的。添加应用程序制件（artifact）作为最新的层有助于减少镜像所占用的磁盘大小。开发人员经常将应用程序制件保存为JAR文件。JAR文件的缺点在于它包含了经常发生变化的元素，比如代码。但是，JAR文件还也包含了不经常发生变化的元素，比如依赖项。Docker镜像版本的变更是以diffs的形式进行存储的。当应用程序的每个版本以JAR文件的方式来进行存储的时候，diff就会非常大，因此会消费很多的磁盘空间。Buildpacks基于变化更频繁的元素，将应用切分为多个分层从减少了空间的占用。

将制件切分为多个分层的功能也能用在Dockerfile中。Buildpacks提供了某种形式的配置，但是Dockerfiles能够对最终形成的镜像提供完全的控制。因此，开发人员有时更喜欢Dockerfile，而不是buildpack。当选择使用Dockerfile的时候，建议将制件切分为多个层。相对于buildpack，这需要更多一点的工作，但这是个一次性的任务。

首先，配置spring-boot-maven-plugin生成分层的JAR：

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <layers>
                    <enabled>true</enabled>
                </layers>
            </configuration>
        </plugin>
    </plugins>
</build>

这个插件配置会确保应用会分为四部分：依赖项、spring-boot-loader、快照依赖（snapshot-dependencies）和应用程序。

如下的程序片段展示了一个多阶段的Dockerfile。在第一步中，应用是按照特定的jarmode参数运行的。这会让四个组成部分各自存放到自己的目录中。在下一个阶段，这四个目录会复制到Docker镜像独立的分层中，随后指定了入口点。

FROM adoptopenjdk:14-jre-hotspot as builder
WORKDIR application
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract
 
FROM adoptopenjdk:14-jre-hotspot
WORKDIR application
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

开发人员可以使用Dockerfile构建Docker镜像，随后就能够基于镜像运行一个容器了：

docker build . --tag infoqdocker run -p8080:8080 infoq

像Kubernetes这样的容器系统会用到存活性和就绪性探针。Kubernetes在为应用生成新版本的时候，会启动一个新的pod。这个新pod在启动时，会和运行旧版本应用程序的旧pod同时存在。当新pod就绪的时候，它会接收流量，旧的pod会被移除掉。但是，当容器就绪的时候，应用通常并没有完全启动起来。这是因为Spring Boot会耗费几秒钟的时间。默认情况下，这意味着旧版本的应用在关闭的时候，尚未完全启动的应用已经在接收流量了。

这可以通过轮询应用内特定的URL来解决，该URL在应用程序启动后才可用。只要URL可用，应用就准备好接收流量了，旧版本则可以删除了。在Kubernetes中，这可以通过所谓的ReadinessProbe来实现。

Spring Boot现在提供了就绪性探针的默认支持。例如，在应用程序的配置中，启用该功能后，就可以通过http://localhost:8080/actuator/health/readiness端点使用该探针了，启用方式是如下的配置：management.health.probes.enabled=true。

除了ReadinessProbe之外，Kubernetes还有一个存活性的概念。它会按照预先定义的间隔验证应用程序的功能是否正常。如果应用没有响应的话，pod将会重启。Spring Boot也为此提供了一个端点：http://localhost:8080/actuator/health/liveness。

这些不同的端点是内置支持的，但是可以对它们进行配置，比如等待数据库启动完成。

优雅关机用来在停止应用之后，系统会为正在进行中的请求维持一定的时间。

如下的代码片段展示了如何启用优雅关机并将超时时间设置为30秒：

server.shutdown=gracefulspring.lifecycle.timeout-per-shutdown-phase=30s

这意味在停止应用后，不允许接收新的请求。但是，在应用彻底停止之前，旧的请求依然还有30秒的时间来等待其完成。

原文链接： Spring Boot 2.3.0 Focuses on the Cloud