进击的 Java ，云原生时代的蜕变(2)

检查一下构建出的 Docker 镜像， ”petclinic-openjdk-openj9“ 的大小为 871MB，而基础镜像 ”adoptopenjdk/openjdk8“ 仅有 300MB!这货也太膨胀了!

$ docker images petclinic-openjdk-hotspot 
REPOSITORY                  TAG                 IMAGE ID            CREATED             SIZE 
petclinic-openjdk-hotspot   latest              469f73967d03        26 hours ago        871MB 

原因是：为了构建 Spring 应用，我们在镜像中引入了一系列编译时依赖，如 Git，Maven 等，并产生了大量临时的文件。然而这些内容在运行时是不需要的。

在著名的软件12要素第五条明确指出了，”Strictly separate build and run stages.“ 严格分离构建和运行阶段，不但可以帮助我们提升应用的可追溯性，保障应用交付的一致性，同时也可以减少应用分发的体积，减少安全风险。

镜像瘦身

Docker 提供了 Multi-stage Build(多阶段构建)，可以实现镜像瘦身。

我们将镜像构建分成两个阶段：

• 在 ”build“ 阶段依然采用 JDK 作为基础镜像，并利用 Maven 进行应用构建;
• 在最终发布的镜像中，我们会采用 JRE 版本作为基础镜像，并从”build“ 镜像中直接拷贝出生成的 jar 文件。这意味着在最终发布的镜像中，只包含运行时所需必要内容，不包含任何编译时依赖，大大减少了镜像体积。

$ cat Dockerfile.openjdk-slim 
FROM adoptopenjdk/openjdk8 AS build 
RUN sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/' /etc/apt/sources.list 
RUN apt-get update 
RUN apt-get install -y \ 
    git \ 
    maven 
WORKDIR /tmp 
RUN git clone https://github.com/spring-projects/spring-petclinic.git 
WORKDIR /tmp/spring-petclinic 
RUN mvn install 
FROM adoptopenjdk/openjdk8:jre8u222-b10-alpine-jre 
COPY --from=build /tmp/spring-petclinic/target/spring-petclinic-2.1.0.BUILD-SNAPSHOT.jar spring-petclinic-2.1.0.BUILD-SNAPSHOT.jar 
CMD ["java","-jar","spring-petclinic-2.1.0.BUILD-SNAPSHOT.jar"] 

查看一下新镜像大小，从 871MB 减少到 167MB!

$ docker build -t petclinic-openjdk-hotspot-slim -f Dockerfile.openjdk-slim . 
... 
$ docker images petclinic-openjdk-hotspot-slim 
REPOSITORY                       TAG                 IMAGE ID            CREATED             SIZE 
petclinic-openjdk-hotspot-slim   latest              d1f1ca316ec0        26 hours ago        167MB 

镜像瘦身之后将大大加速应用分发速度，我们是否有办法优化应用的启动速度呢?

从 JIT 到 AOT —启动提速

为了解决 Java 启动的性能瓶颈，我们首先需要理解 JVM 的实现原理。

（编辑：ASP站长网）