云原生时代的Java应用优化实践-低调大师

云原生时代的Java应用优化实践

2022-03-02 541

Java从诞生至今已经走过了26年，在这26年的时间里，Java应用从未停下脚步，从最开始的单机版到web应用再到现在的微服务应用，依靠其强大的生态，它仍然占据着当今语言之争的“天下第一”的宝座。但在如今的云原生serverless时代，Java应用却遭遇到了前所未有的挑战。

在云原生时代，云原生技术利用各种公有云、私有云和混合云等新型动态环境，构建和运行可弹性扩展的应用。而我们应用也越来越呈现出以下特点：

基于容器镜像构建

Java诞生之初，靠着“一次编译，到处运行”的口号，以语言层虚拟化的方式，在那个操作系统平台尚不统一的年代，建立起了优势。但如今步入云原生时代，以Docker为首的容器技术同样提出了“一次构建，到处运行”的口号，通过操作系统虚拟化的方式，为应用程序提供了环境兼容性和平台无关性。因此，在云原生时代的今天，Java“一次编译，到处运行”的优势，已经被容器技术大幅度地削弱，不再是大多数服务端开发者技术选型的主要考虑因素了。此外，因为是基于镜像，云原生时代对镜像大小可以说是十分敏感，而包含了JDK的Java应用动辄几百兆的镜像大小，无疑是越来越不符合时代的要求。

生命周期缩短，并经常需要弹性扩缩容

灵活和弹性可以说是云原生应用的一个显著特性，而这也意味着应用需要具备更短的冷启动时间，以应对灵活弹性的要求。Java应用往往面向长时间大规模程序而设计，JVM的JIT和分层编译优化技术，会使得Java应用在不断的运行中进行自我优化，并在一段时间后达到性能顶峰。但与运行性能相反，Java应用往往有着缓慢的启动时间。流行的框架（例如Spring）中大量的类加载、字节码增强和初始化逻辑，更是加重了这一问题。这无疑是与云原生时代的理念是相悖的。

对计算资源用量敏感

进入公有云时代，应用往往是按用量付费，这意味着应用所需要的计算资源就变的十分重要。Java应用固有的内存占用多的劣势，在云原生时代被放大，相对于其他语言，使用起来变得更加“昂贵”。

由此可见，在云原生时代，Java应用的优势正在不断被蚕食，而劣势却在不断的被放大。因此，如何让我们的应用更加顺应时代的发展，使Java语言能在云原生时代发挥更大的价值，就成了一个值得探讨的话题。为此，笔者将尝试跳出语言对比的固有思路，为大家从一个更全局的角度，来看看在云原生应用发布的全流程中，我们都能够做哪些优化。

镜像构建优化

Dockerfile

从Dockerfile说起是因为它是最基础的，也是最简单的优化，它可以简单的加快我们的应用构建镜像和拉取镜像的时间。

以一个Springboot应用为例，我们通常会看到这种样子的Dockerfile：

FROM openjdk:8-jdk-alpine
COPY app.jar /
ENTRYPOINT ["java","-jar","/app.jar"]

足够简单清晰，但很显然，这并不是一个很好的Dockerfile，因为它没有利用到Image layer去进行效率更高的缓存。

我们都知道，Docker拥有足够高效的缓存机制，但如果不好好的应用这一特性，而是简单的将Jar包打成单一layer镜像，就会导致，即使应用只改动一行代码，我们也需要重新构建整个Springboot Jar包，而这其中Spring的庞大依赖类库其实都没有发生过更改，这无疑是一种得不偿失的做法。因此，将应用的所有依赖库作为一个单独的layer显然是一个更好的方案。

因此，一个更合理的Dockerfile应该长这个样子：

FROM openjdk:8-jdk-alpine
ARG DEPENDENCY=target/dependency
COPY ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY ${DEPENDENCY}/META-INF /app/META-INF
COPY ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","HelloApplication"]

这样，我们就可以充分利用Image layer cache来加快构建镜像和拉取镜像的时间。

构建组件

在Docker占有镜像构建的绝对话语权的今天，我们在实际开发过程中，往往会忽视构建组件的选择，但事实上，选择一个高效的构建组件，往往能使我们的构建效率事半功倍。

传统的`docker build`存在哪些问题？

在Docker v18.06之前的docker build会存在一些问题：

改变Dockerfile中的任意一行，就会使之后的所有行的缓存失效

# 假设只改变此Dockerfile中的EXPOSE端口号
# 那么接下来的RUN命令的缓存就会失效
FROM debian
EXPOSE 80
RUN apt update && apt install –y HEAVY-PACKAGES

多阶段并行构建效率不佳

# 即使stage0和stage1之间并没有依赖
# docker也无法并行构建，而是选择串行
FROM openjdk:8-jdk AS stage0
RUN ./gradlew clean build

FROM openjdk:8-jdk AS stage1
RUN ./gradlew clean build

FROM openjdk:8-jdk-alpine
COPY --from=stage0 /app-0.jar /
COPY --from=stage1 /app-1.jar /

无法提供编译历史缓存

# 单纯的RUN命令无法提供编译历史缓存
# 而RUN --mount的新语法在旧版本docker下无法支持
RUN ./gradlew build
# since Docker v18.06
# syntax = docker/dockerfile:1.1-experimental
RUN --mount=type=cache,target=/.cache ./gradlew build

镜像push和pull的过程中存在压缩和解压的固有耗时

如上图所示，在传统的docker pull push阶段，存在着pack和unpack的耗时，而这一部分并非必须的

针对这些固有的弊病，业界也一直在积极的探讨，并诞生了一些可以顺应新时代的构建工具。

新一代构建组件：

在最佳的新一代构建工具选择上，是一个没有银弹的话题，但通过一些简单的对比，我们仍能选出一个最适合的构建工具，我们认为，一个适合云原生平台的构建工具应该至少具备以下几个特点：

能够支持完整的Dockerfile语法，以便应用平顺迁移
能够弥补上述传统Docker构建的缺点
能够在非root privilege模式下执行（在基于Kubernetes的CICD环境中显得尤为重要）

因此，Buildkit就脱颖而出，这个由Docker公司开发，目前由社区和Docker公司合理维护的“含着金钥匙出生”的新一代构建工具，拥有良好的扩展性、极大地提高了构建速度，并提供了更好的安全性。Buildkit支持全部的Dockerfile语法，能更高效的命中构建缓存，增量的转发build context，多并发直接推送镜像层至镜像仓库。

（Buildkit与其他构建组件的对比）

（Buildkit的构建效率）

镜像大小

为了在拉取和推送镜像过程中更高的控制耗时，我们通常会尽可能的减少镜像的大小。

Alpine Linux是许多Docker容器首选的基础镜像，因为它只有5 MB大小，比起其他Cent OS、Debain 等动辄一百多MB的发行版来说，更适合用于容器环境。不过Alpine Linux为了尽量瘦身，默认是用musl作为C标准库的，而非传统的glibc（GNU C library），因此要以Alpine Linux为基础制作OpenJDK镜像，必须先安装glibc，此时基础镜像大约有12 MB。

在JEP 386中，OpenJDK将上游代码移植到musl，并通过兼容性测试。这一特性已经在Java 16中发布。这样制作出来的镜像仅有41MB，不仅远低于Cent OS的OpenJDK（大约 396 MB），也要比官方的slim版（约200MB）要小得多。

应用启动加速

让我们首先来看一下，一个Java应用在启动过程中，会有哪些阶段

这个图代表了Java运行时各个阶段的生命周期，可以看到它要经过五个阶段，首先是VM init虚拟机的初始化阶段，然后是App init应用的初始化阶段，再经过App active(warmup)的应用预热时期，在预热一段时间后进入App active(steady)达到性能巅峰期，最后应用结束完成整个生命周期。

使用AppCDS

从上面的图中，我们不难发现，蓝色的CL(ClassLoad)部分，实际长占用了Java应用启动的阶段的一大部分时间。而Java也一直在致力于减少应用启动的ClassLoad时间。

从JDK 1.5开始，HotSpot就提供了CDS(Class Data Sharing)功能，很长一段时间以来，它的功能都非常有限，并且只有部分商业化。早期的CDS致力于，在同一主机上的JVM实例之间“共享”同样需要加载一次的类，但是遗憾的是早期的CDS不能处理由AppClassloader加载的类，这使得它在实际开发实践中，显得比较“鸡肋”。

但在从OpenJDK 10 (2018) 开始，AppCDS【JEP 310】在CDS的基础上，加入了对AppClassloader的适配，它的出现，使得CDS技术变得广泛可用并且更加适用。尤其是对于动辄需要加载数千个类的Spring Boot程序，因为JVM不需要在每个实例的每次启动时加载（解析和验证）这些类，因此，启动应该变得更快并且内存占用应该更小。看起来，AppCDS的一切都很美好，但实际使用也确实如此吗？

当我们试图使用AppCDS时，它应该包含以下几个步骤：

使用-XX:DumpLoadedClassList参数来获取我们希望在应用程序实例之间共享的类
使用-Xshare:dump参数将类存储到适合内存映射的存档(.jsa文件)中
使用-Xshare:on参数在启动时将存档附加到每个应用程序实例

乍一看，使用AppCDS似乎很容易，只需3个简单的步骤。但是，在实际使用过程中，你会发现每一步都可能变成一次带有特定JVM Options的应用启动，我们无法简单的通过一次启动来获得可重复使用的类加载存档文件。尽管在JDK 13中，提供了新的动态CDS【JEP 350】，来将上述步骤1和步骤2合并为一步。但在目前流行的JDK 11中，我们仍然逃不开上述三个步骤（三次启动）。因此，使用AppCDS往往意味着对应用的启动过程进行复杂的改造，并伴随着更为漫长的首次编译和启动时间。

同时需要注意的是，在使用AppCDS时，许多应用的类路径将会变得更加混乱：它们既位于原来的位置（JAR包）中，同时又位于新的共享存档（.jsa文件）中。在我们应用开发的过程中，我们会不断更改、删除原来的类，而JVM会从新的类中进行解析。这种情况所带来的危险是显而易见的：如果类归档文件保持不变，那么类不匹配是迟早的事，我们会遇到典型的“Classpath Hell”问题。

JVM无法阻止类的变化，但它至少应该能够在适当的时候检测到类不匹配。然而，在JVM的实现中，并没有检测每一个单独的类，而是选择去比较整个类路径，因此，在AppCDS的官方描述中，我们可以找到这样一句话：

The classpath used with -Xshare:dump must be the same as, or be a prefix of, the classpath used with -Xshare:on. Otherwise, the JVM will print an error message

即第二部步归档文件创建时使用的类路径必须与运行时使用的类路径相同（或前者是后者的前缀）。

但这是一个相当含糊的陈述，因为类路径可能以几种不同的方式形成，例如：

从带有Jar包的目录中直接加载.class文件，例如java com.example.Main
使用通配符，扫描带有Jar包的目录，例如java -cp mydir/* com.example.Main
使用明确的Jar包路径，例如java -cp lib1.jar:lib2.jar com.example.Main

在这些方式中，AppCDS唯一支持的方式只有第三种，即是显式列出Jar包路径。这使得那些使用了大规模Jar包依赖的应用的启动语句变得十分繁琐。

同时，我们也要必须注意到，这种显式列出Jar包路径的方式并不会进行递归查找，即它只会在包含所有class文件的FatJar中生效。这意味着使用SpringBoot框架的嵌套Jar包结构，将很难利用AppCDS技术所带来的便利。

因此，SpringBoot如果想在云原生环境中使用AppCDS，就必须进行应用侵入性的改造，不去使用SpringBoot默认的嵌套Jar启动结构，而是用类似maven shade plugin重新打FatJar，并在程序中显示的声明能让程序自然关闭的接口或参数，通过Volume挂载或者Dockerfile改造的方式，来存储和加载类的归档文件。这里给出一个改造过的Dockerfile的示例：

# 这里假设我们已经做过FatJar改造，并且Jar包中包含应用运行所需的全部class文件
FROM eclipse-temurin:11-jre as APPCDS

COPY target/helloworld.jar /helloworld.jar

# 运行应用，同时设置一个'--appcds'参数使程序在运行后能够停止
RUN java -XX:DumpLoadedClassList=classes.lst -jar helloworld.jar --appcds=true

# 使用上一步得到的class列表来生成类归档文件
RUN java -Xshare:dump -XX:SharedClassListFile=classes.lst -XX:SharedArchiveFile=appcds.jsa --class-path helloworld.jar

FROM eclipse-temurin:11-jre

# 同时复制Jar包和类归档文件
COPY --from=APPCDS /helloworld.jar /helloworld.jar
COPY --from=APPCDS /appcds.jsa /appcds.jsa

# 使用-Xshare:on参数来启动应用
ENTRYPOINT java -Xshare:on -XX:SharedArchiveFile=appcds.jsa -jar helloworld.jar

由此可见，使用AppCDS还是要付出相当多的学习和改造成本的，并且许多改造都会对我们的应用产生入侵。

JVM优化

除了构建阶段和启动阶段，我们还可以从JVM本身入手，根据云原生环境的特点，进行针对性的优化。

使用可以感知容器内存资源的JDK

在虚拟机和物理机中，对于 CPU 和内存分配，JVM会从常见位置（例如，Linux 中的/proc/cpuinfo和/proc/meminfo）查找其可以使用的CPU和内存。但是，在容器中运行时，CPU和内存限制条件存储在/proc/cgroups/...中。较旧版本的JDK会继续在/proc（而不是/proc/cgroups）中查找，这可能会导致CPU和内存用量超出分配的上限，并因此引发多种严重的问题：

线程过多，因为线程池大小由Runtime.availableProcessors()配置
JVM的对内存使用超出容器内存上限。并导致容器被OOMKilled。

JDK 8u131首先实现了UseCGroupMemoryLimitForHeap的参数。但这个参数存在缺陷，为应用添加UnlockExperimentalVMOptions和UseCGroupMemoryLimitForHeap参数后，JVM确实可以感知到容器内存，并控制应用的实际堆大小。但是这并没有充分利用我们为容器分配的内存。

因此JVM提供-XX:MaxRAMFraction标志来帮助更好的计算堆大小，MaxRAMFraction默认值是4（即除以4），但它是一个分数，而不是一个百分比，因此很难设置一个能有效利用可用内存的值。

JDK 10附带了对容器环境的更好支持。如果在Linux容器中运行Java应用程序，JVM将使用UseContainerSupport选项自动检测内存限制。然后，通过InitialRAMPercentage、MaxRAMPercentage和MinRAMPercentage来进行对内存控制。这时，我们使用的是百分比而不是分数，这将更加准确。

默认情况下，UseContainerSupport参数是激活的，MaxRAMPercentage是25%，MinRAMPercentage是50%。

需要注意的是，这里MinRAMPercentage并不是用来设置堆大小的最小值，而是仅当物理服务器（或容器）中的总可用内存小于250MB时，JVM将用此参数来限制堆的大小。

同理，MaxRAMPercentage是当物理服务器（或容器）中的总可用内存大小超过250MB时，JVM将用此参数来限制堆的大小。

这几个参数已经向下移植到JDK 8u191。UseContainerSupport默认情况下是激活的。我们可以设置-XX:InitialRAMPercentage=50.0 -XX:MaxRAMPercentage=80.0来JVM感知并充分利用容器的可用内存。需要注意的是，在指定-Xms -Xmx时，InitialRAMPercentage和MaxRAMPercentage将会失效。

关闭优化编译器

默认情况下，JVM有多个阶段的JIT编译。虽然这些阶段可以逐渐提高应用的效率，但它们也会增加内存使用的开销，并增加启动时间。

对于短期运行的云原生应用，可以考虑使用以下参数来关闭优化阶段，以牺牲长期运行效率来换取更短的启动时间。

JAVA_TOOL_OPTIONS="-XX:+TieredCompilation -XX:TieredStopAtLevel=1"

关闭类验证

当JVM将类加载到内存中以供执行时，它会验证该类未被篡改并且没有恶意修改或损坏。但在云原生环境，CI/CD流水线通常也由云原生平台提供，这表示我们的应用的编译和部署是可信的，因此我们应该考虑使用以下参数关闭验证。如果在启动时加载大量类，则关闭验证可能会提高启动速度。

JAVA_TOOL_OPTIONS="-noverify"

减小线程栈大小

大多数Java Web应用都是基于每个连接一个线程的模式。每个Java线程都会消耗本机内存（而不是堆内存）。这称为线程栈，并且每个线程默认为1 MB。如果您的应用处理100个并发请求，则它可能至少有100个线程，这相当于使用了100MB的线程栈空间。该内存不计入堆大小。我们可以使用以下参数来减小线程栈大小。

JAVA_TOOL_OPTIONS="-Xss256k"

需要注意如果减小得太多，则将出现java.lang.StackOverflowError。您可以对应用进行分析，并找到要配置的最佳线程栈大小。

使用TEM进行零改造的Java应用云原生优化

通过上面的分析，我们可以看出，如果想要让我们的Java应用能在云原生时代发挥出最大实力，是需要付出许多侵入性的改造和优化操作的。那么有没有一种方式能够帮助我们零改造的开展Java应用云原生优化？

腾讯云的TEM弹性微服务就为广大Java开发者提供了一种应用零改造的最佳实践，帮助您的Java应用以最优姿态快速上云。使用TEM您可以享受的以下优势：

零构建部署。直接选择使用Jar包/War包交付，无需自行构建镜像。TEM默认提供能充分利用构建缓存的构建流程，使用新一代构建利器Buildkit进行高速构建，构建速度优化50%以上，并且整个构建流程可追溯，构建日志可查，简单高效。

（直接使用Jar包部署）

（构建日志可查）

（构建速度对比）

零改造加速。直接使用KONA Jdk 11/Open Jdk 11进行应用加速，并且默认支持SpringBoot应用零改造加速。您无需改造原有的SpringBoot嵌套Jar包结构，TEM将直接提供Java应用加速的最佳实践，实例扩容时的启动时间将缩短至10%～40%。

（不使用应用加速，规格1c2g）

（使用应用加速，规格1c2g）

（应用启动速度对比，以spring petclinic为例，规格1c2g）

零运维监控。使用SkyWalking为您的Java应用进行应用级别的监控，您可以直观的查看JVM堆内存，GC次数/耗时，接口RT/QPS等关键参数，帮助您即使找到应用性能瓶颈。

（应用JVM监控）

极致弹性。TEM默认提供使用率较高的定时弹性策略和基于资源的弹性策略，为您的应用提供秒级的弹性性能，帮助您应对流量洪峰，并能在实例闲置时及时节省资源。

（指标弹性策略）

（定时弹性策略）

总结

工欲善其事，必先利其器。在步入云原生时代的今天，如何让您的Java应用的部署效率和运行性能最大化，这对所有开发者都是一个挑战。而TEM作为一款面向微服务应用的Serverless PaaS平台，将成为您手中的“云端利器”，TEM将致力于为企业和开发者服务，帮助您的业务以最快速、便捷、省心的姿态，无忧上云，享受云原生时代的便利。

腾讯云弹性微服务（Tencent Cloud Elastic Microservice，TEM）是面向微服务应用的 Serverless 平台，实现 Serverless 与微服务的完美结合，提供开箱即用的微服务解决方案。目前腾讯云最新一代Serverless微服务应用管理平台TEM正在限时免费，速来官网体验使用！

参考文档

http://seanthefish.com/2020/11/11/jvm-in-container/ https://www.infoq.cn/article/rqfww2r2zpyqiolc1wbe https://medium.com/@toparvion/appcds-for-spring-boot-applications-first-contact-6216db6a4194 https://events19.linuxfoundation.org/wp-content/uploads/2017/11/Comparing-Next-Generation-Container-Image-Building-Tools-OSS-Akihiro-Suda.pdf https://static.sched.com/hosted_files/kccnceu19/12/Building%20images%20%20efficiently%20and%20securely%20on%20Kubernetes%20with%20BuildKit.pdf

微信关注我们

原文链接：https://my.oschina.net/u/4587289/blog/5470798

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

数据治理一体化实践之体系化建模

数字经济的快速发展，给企业的经营带来了新的机遇和挑战，如何有效开展数据治理，打破数据孤岛，充分发挥数据的业务价值，保护数据安全，已成为业界的热门话题。本文基于美团配送数据治理的历程，分享了数据定义、模型设计、数据生产三环节统一的配送数据“底座”的建设与实践。 1 前言随着数字经济的快速发展，数据已经成为新的生产要素。如何有效地开展数据治理工作，提升数据质量，打破数据孤岛，充分发挥数据的业务价值，已成为业界的热门话题。本文基于美团配送数据治理的历程，重点和大家分享一下配送数据“底座”的建设与实践，如何通过体系化建模建立起数据定义到数据生产的桥梁，达成数据定义、模型设计、数据生产三个环节的统一，消除因数据标准缺失和执行不到位引发的数据信任问题，在高质量地实现数据到信息的转化的同时，为后续的数据便捷消费提供数据和元数据保障。希望能给从事数据治理方向的同学在实现数据到资产的转化过程提供一些参考和借鉴。 2 什么是体系化建模体系化建模是以维度建模为理论基础，以事前治理的理念驱动，让元数据贯穿其中的建模流程，上承指标、维度的定义，下接实际的数据生产。首先，通过高层模型设计，将业务指标结构化拆解...

2022-03-02

457

原文作者：Libby Meren 原文链接：支持开源，打造更安全的世界：F5 NGINX 宣布赞助 Let's Encrypt 和 OpenSSL - NGINX 转载来源：NGINX官方网站 F5 NGINX 的目标不仅是构建赋能现代应用和平台运营实践的优秀开源软件，而且还致力于创造更加安全的技术世界。技术已经愈加成为我们日常生活中不可或缺的一部分。我们在为自己的付出感到骄傲的同时，也认识到网络安全需要大家共同守护。很荣幸向大家宣布，我们赞助了两个关系着全球技术安全的开源项目 —— Let's Encrypt 和 OpenSSL。 Let's Encrypt Let's Encrypt 让数字证书的获取和部署实现了真正意义上的免费，降低了安全防护的门槛。更具体地说，Let’s Encrypt 的使命是推动 HTTPS 的广泛采用，构建更安全的万维网。为了实现这个目标，Let's Encrypt 运营着全球规模最大的证书颁发机构，为超过 2.6 亿个网站提供安全保护，并通过将原本繁琐的手动步骤（例如支付、Web 服务器配置、电子邮件验证和证书更新）自动化来简化证书管理。毫不夸张地...

2022-03-02

513

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。