写点什么

进击的 Java ,云原生时代的蜕变

  • 2019-11-07
  • 本文字数:7849 字

    阅读完需:约 26 分钟

进击的 Java ,云原生时代的蜕变

在企业软件领域,Java 依然是绝对王者,但它让开发者既爱又恨。一方面因为其丰富的生态和完善的工具支持,可以极大提升了应用开发效率;但在运行时效率方面,Java 也背负着”内存吞噬者“,“CPU 撕裂者“的恶名,持续受到 NodeJS、Python、Golang 等新老语言的挑战。


在技术社区,我们经常看到有人在唱衰 Java 技术,认为其不再符合云原生计算发展的趋势。先抛开上面这些观点,我们首先思考一下云原生对应用运行时的不同需求:


  • 体积更小:对于微服务分布式架构而言,更小的体积意味着更少的下载带宽,更快的分发下载速度。

  • 启动速度更快:对于传统单体应用,启动速度与运行效率相比不是一个关键的指标。原因是,这些应用重启和发布频率相对较低。然而对于需要快速迭代、水平扩展的微服务应用而言,更快的的启动速度就意味着更高的交付效率,和更加快速的回滚。尤其当你需要发布一个有数百个副本的应用时,缓慢的启动速度就是时间杀手。对于 Serverless 应用而言,端到端的冷启动速度则更为关键,即使底层容器技术可以实现百毫秒资源就绪,如果应用无法在 500ms 内完成启动,用户就会感知到访问延迟。

  • 占用资源更少:运行时更低的资源占用,意味着更高的部署密度和更低的计算成本。同时,在 JVM 启动时需要消耗大量 CPU 资源对字节码进行编译,降低启动时资源消耗,可以减少资源争抢,更好保障其他应用 SLA。

  • 支持水平扩展:JVM 的内存管理方式导致其对大内存管理的相对低效,一般应用无法通过配置更大的 heap size 实现性能提升,很少有 Java 应用能够有效使用 16G 内存或者更高。另一方面,随着内存成本的下降和虚拟化的流行,大内存配比已经成为趋势。所以我们一般是采用水平扩展的方式,同时部署多个应用副本,在一个计算节点中可能运行一个应用的多个副本来提升资源利用率。

热身准备

熟悉 Spring 框架的开发者大多对 Spring Petclinic 不会陌生。本文将借助这个著名示例应用来演示如何让我们的 Java 应用变得更小、更快、更轻、更强大!



我们 fork 了 IBM 的 Michael Thompson 的示例,并做了一些调整。


$ git clone https://github.com/denverdino/adopt-openj9-spring-boot$ cd adopt-openj9-spring-boot
复制代码


首先,我们会为 PetClinic 应用构建一个 Docker 镜像。在 Dockerfile 中,我们利用 OpenJDK 作为基础镜像,安装 Maven,下载、编译、打包 Spring PetClinic 应用,最后设置镜像的启动参数完成镜像构建。


$ cat Dockerfile.openjdkFROM adoptopenjdk/openjdk8RUN sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/' /etc/apt/sources.listRUN apt-get updateRUN apt-get install -y \    git \    mavenWORKDIR /tmpRUN git clone https://github.com/spring-projects/spring-petclinic.gitWORKDIR /tmp/spring-petclinicRUN mvn installWORKDIR /tmp/spring-petclinic/targetCMD ["java","-jar","spring-petclinic-2.1.0.BUILD-SNAPSHOT.jar"]
复制代码


构建镜像并执行


$ docker build -t petclinic-openjdk-hotspot -f Dockerfile.openjdk .$ docker run --name hotspot -p 8080:8080 --rm petclinic-openjdk-hotspot              |\      _,,,--,,_             /,`.-'`'   ._  \-;;,_  _______ __|,4-  ) )_   .;.(__`'-'__     ___ __    _ ___ _______ |       | '---''(_/._)-'(_\_)   |   |   |   |  |  | |   |       | |    _  |    ___|_     _|       |   |   |   |   |_| |   |       | __ _ _ |   |_| |   |___  |   | |       |   |   |   |       |   |       | \ \ \ \ |    ___|    ___| |   | |      _|   |___|   |  _    |   |      _|  \ \ \ \ |   |   |   |___  |   | |     |_|       |   | | |   |   |     |_    ) ) ) ) |___|   |_______| |___| |_______|_______|___|_|  |__|___|_______|  / / / / ==================================================================/_/_/_/...2019-09-11 01:58:23.156  INFO 1 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''2019-09-11 01:58:23.158  INFO 1 --- [           main] o.s.s.petclinic.PetClinicApplication     : Started PetClinicApplication in 7.458 seconds (JVM running for 8.187)
复制代码


可以通过 http://localhost:8080/ 访问应用界面。


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


$ docker images petclinic-openjdk-hotspotREPOSITORY                  TAG                 IMAGE ID            CREATED             SIZEpetclinic-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-slimFROM adoptopenjdk/openjdk8 AS buildRUN sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/' /etc/apt/sources.listRUN apt-get updateRUN apt-get install -y \    git \    mavenWORKDIR /tmpRUN git clone https://github.com/spring-projects/spring-petclinic.gitWORKDIR /tmp/spring-petclinicRUN mvn installFROM adoptopenjdk/openjdk8:jre8u222-b10-alpine-jreCOPY --from=build /tmp/spring-petclinic/target/spring-petclinic-2.1.0.BUILD-SNAPSHOT.jar spring-petclinic-2.1.0.BUILD-SNAPSHOT.jarCMD ["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-slimREPOSITORY                       TAG                 IMAGE ID            CREATED             SIZEpetclinic-openjdk-hotspot-slim   latest              d1f1ca316ec0        26 hours ago        167MB
复制代码


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

从 JIT 到 AOT — 启动提速

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


为了实现“一次编写,随处运行”的能力,Java 程序会被编译成实现架构无关的字节码。JVM 在运行时将字节码转换成本地机器码执行。这个转换过程决定了 Java 应用的启动和运行速度。为了提升执行效率,JVM 引入了 JIT compiler(Just in Time Compiler,即时编译器),其中 Sun/Oracle 公司的 HotSpot 是最著名 JIT 编译器实现。


HotSpot 提供了自适应优化器,可以动态分析、发现代码执行过程中的关键路径,并进行编译优化。HotSpot 的出现极大提升了 Java 应用的执行效率,在 Java 1.4 以后成为了缺省的 VM 实现。但是 HotSpot VM 在启动时才对字节码进行编译,一方面导致启动时执行效率不高,一方面编译和优化需要很多的 CPU 资源,拖慢了启动速度。我们是否可以优化这个过程,提升启动速度呢?


熟悉 Java 江湖历史的同学应该会知道 IBM J9 VM,它是用于 IBM 企业级软件产品的一款高性能的 JVM,帮助 IBM 奠定了商业应用平台中间件的霸主地位。2017 年 9 月,IBM 将 J9 捐献给 Eclipse 基金会,并更名 Eclipse OpenJ9,开启开源之旅。


OpenJ9 提供了 Shared Class Cache (SCC 共享类缓存) 和 Ahead-of-Time (AOT 提前编译) 技术,显著减少了 Java 应用启动时间。


SCC 是一个内存映射文件,包含了 J9 VM 对字节码的执行分析信息和已经编译生成的本地代码。开启 AOT 编译后,会将 JVM 编译结果保存在 SCC 中,在后续 JVM 启动中可以直接重用。与启动时进行的 JIT 编译相比,从 SCC 加载预编译的实现要快得多,而且消耗的资源要更少。启动时间可以得到明显改善。


我们开始构建一个包含 AOT 优化的 Docker 应用镜像:


$cat Dockerfile.openj9.warmedFROM adoptopenjdk/openjdk8-openj9 AS buildRUN sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/' /etc/apt/sources.listRUN apt-get updateRUN apt-get install -y \    git \    mavenWORKDIR /tmpRUN git clone https://github.com/spring-projects/spring-petclinic.gitWORKDIR /tmp/spring-petclinicRUN mvn installFROM adoptopenjdk/openjdk8-openj9:jre8u222-b10_openj9-0.15.1-alpineCOPY --from=build /tmp/spring-petclinic/target/spring-petclinic-2.1.0.BUILD-SNAPSHOT.jar spring-petclinic-2.1.0.BUILD-SNAPSHOT.jar# Start and stop the JVM to pre-warm the class cacheRUN /bin/sh -c 'java -Xscmx50M -Xshareclasses -Xquickstart -jar spring-petclinic-2.1.0.BUILD-SNAPSHOT.jar &' ; sleep 20 ; ps aux | grep java | grep petclinic | awk '{print $1}' | xargs kill -1CMD ["java","-Xscmx50M","-Xshareclasses","-Xquickstart", "-jar","spring-petclinic-2.1.0.BUILD-SNAPSHOT.jar"]
复制代码


其中 Java 参数 -Xshareclasses 开启 SCC,-Xquickstart 开启 AOT。


在 Dockerfile 中,我们运用了一个技巧来预热 SCC。在构建过程中启动 JVM 加载应用,并开启 SCC 和 AOT,在应用启动后停止 JVM。这样就在 Docker 镜像中包含了生成的 SCC 文件。


然后,我们来构建 Docker 镜像并启动测试应用,


$ docker build -t petclinic-openjdk-openj9-warmed-slim -f Dockerfile.openj9.warmed-slim .$ docker run --name hotspot -p 8080:8080 --rm petclinic-openjdk-openj9-warmed-slim...2019-09-11 03:35:20.192  INFO 1 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''2019-09-11 03:35:20.193  INFO 1 --- [           main] o.s.s.petclinic.PetClinicApplication     : Started PetClinicApplication in 3.691 seconds (JVM running for 3.952)
复制代码


可以看到,启动时间已经从之前的 8.2s 减少到 4s,提升近 50%。


在这个方案中,我们一方面将耗时耗能的编译优化过程转移到构建时完成,一方面采用以空间换时间的方法,将预编译的 SCC 缓存保存到 Docker 镜像中。在容器启动时,JVM 可以直接使用内存映射文件来加载 SCC,优化了启动速度和资源占用。


这个方法另外一个优势是:由于 Docker 镜像采用分层存储,同一个宿主机上的多个 Docker 应用实例会共享同一份 SCC 内存映射,可以大大减少在单机高密度部署时的内存消耗。


下面我们做一下资源消耗的比较,我们首先利用基于 HotSpot VM 的镜像,同时启动 4 个 Docker 应用实例,30s 后利用docker stats查看资源消耗。


$ ./run-hotspot-4.sh...Wait a while ...CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS0fa58df1a291        instance4           0.15%               597.1MiB / 5.811GiB   10.03%              726B / 0B           0B / 0B             3348f021d728bb        instance3           0.13%               648.6MiB / 5.811GiB   10.90%              726B / 0B           0B / 0B             33a3abb10078ef        instance2           0.26%               549MiB / 5.811GiB     9.23%               726B / 0B           0B / 0B             336a65cb1e0fe5        instance1           0.15%               641.6MiB / 5.811GiB   10.78%              906B / 0B           0B / 0B             33...
复制代码


然后使用基于 OpenJ9 VM 的镜像,同时启动 4 个 Docker 应用实例,并查看资源消耗。


$ ./run-openj9-warmed-4.sh...Wait a while ...CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS3a0ba6103425        instance4           0.09%               119.5MiB / 5.811GiB   2.01%               1.19kB / 0B         0B / 446MB          39c07ca769c3e7        instance3           0.19%               119.7MiB / 5.811GiB   2.01%               1.19kB / 0B         16.4kB / 120MB      390c19b0cf9fc2        instance2           0.15%               112.1MiB / 5.811GiB   1.88%               1.2kB / 0B          22.8MB / 23.8MB     3995a9c4dec3d6        instance1           0.15%               108.6MiB / 5.811GiB   1.83%               1.45kB / 0B         102MB / 414MB       39...
复制代码


与 HotSpot VM 相比,OpenJ9 的场景下应用内存占用从平均 600MB 下降到 120MB。惊喜不惊喜?


通常而言,HotSpot JIT 比 AOT 可以进行更加全面和深入的执行路径优化,从而有更高的运行效率。为了解决这个矛盾,OpenJ9 的 AOT SCC 只在启动阶段生效,在后续运行中会继续利用 JIT 进行分支预测、代码内联等深度编译优化。


更多关于 OpenJ9 SCC 和 AOT 的技术介绍,请参考



思考:与 C/C++,Golang, Rust 等静态编译语言不同,Java 采用 VM 方式运行,提升了应用可移植性的同时牺牲了部分性能。我们是否可以将 AOT 做到极致?完全移除字节码到本地代码的编译过程?

原生代码编译

为了将 Java 应用编译成本地可执行代码,我们首先要解决 JVM 和应用框架在运行时的动态性挑战。JVM 提供了灵活的类加载机制,Spring 的依赖注入(DI,Dependency-injection)可以实现运行时动态类加载和绑定。在 Spring 框架中,反射,Annotation 运行时处理器等技术也被广泛应用。这些动态性一方面提升了应用架构的灵活性和易用性,另一方面也降低了应用的启动速度,使得 AOT 原生编译和优化变得非常复杂。


为了解决这些挑战,社区有很多有趣的探索,Micronaut 是其中一个优秀代表。与 Spring 框架序不同,Micronaut 提供了编译时的依赖注入和 AOP 处理能力,并最小化反射和动态代理的使用。Micronaut 应用有着更快的启动速度和更低的内存占用。更加让我们更感兴趣的是 Micronaut 支持与 GraalVM 配合,可以将 Java 应用编译成为本地执行代码全速运行。


注:GraalVM 是 Oracle 推出的一种新型通用虚拟机,支持多种语言,可以将 Java 应用程序编译为本地原生应用。



原图


下面开始我们的探险,我们利用 Mitz 提供的 Micronaut 版本 PetClinic 示例工程并做了一点点调整。(使用 Graal VM 19.2)


$ git clone https://github.com/denverdino/micronaut-petclinic$ cd micronaut-petclinic
复制代码


其中 Docker 镜像的内容如下:


$ cat DockerfileFROM maven:3.6.1-jdk-8 as buildCOPY ./ /micronaut-petclinic/WORKDIR /micronaut-petclinicRUN mvn packageFROM oracle/graalvm-ce:19.2.0 as graalvmRUN gu install native-imageWORKDIR /workCOPY --from=build /micronaut-petclinic/target/micronaut-petclinic-*.jar .RUN native-image --no-server -cp micronaut-petclinic-*.jarFROM frolvlad/alpine-glibcEXPOSE 8080WORKDIR /appCOPY --from=graalvm /work/petclinic .CMD ["/app/petclinic"]
复制代码


其中


  • 在 “build” 阶段,利用 Maven 构建 Micronaut 版本的 PetClinic 应用,

  • 在 “graalvm” 阶段,我们通过 native-image 将 PetClinic jar 文件转化成可执行文件。* 在最终阶段,将本地可执行文件加入一个 Alpine Linux 基础镜像


构建应用


$ docker-compose build
复制代码


启动测试数据库


$ docker-compose up db
复制代码


启动测试应用


$ docker-compose up appmicronaut-petclinic_db_1 is up-to-dateStarting micronaut-petclinic_app_1 ... doneAttaching to micronaut-petclinic_app_1app_1  | 04:57:47.571 [main] INFO  org.hibernate.dialect.Dialect - HHH000400: Using dialect: org.hibernate.dialect.PostgreSQL95Dialectapp_1  | 04:57:47.649 [main] INFO  org.hibernate.type.BasicTypeRegistry - HHH000270: Type registration [java.util.UUID] overrides previous : org.hibernate.type.UUIDBinaryType@5f4e0f0app_1  | 04:57:47.653 [main] INFO  o.h.tuple.entity.EntityMetamodel - HHH000157: Lazy property fetching available for: com.example.micronaut.petclinic.owner.Ownerapp_1  | 04:57:47.656 [main] INFO  o.h.e.t.j.p.i.JtaPlatformInitiator - HHH000490: Using JtaPlatform implementation: [org.hibernate.engine.transaction.jta.platform.internal.NoJtaPlatform]app_1  | 04:57:47.672 [main] INFO  io.micronaut.runtime.Micronaut - Startup completed in 159ms. Server Running: http://1285c42bfcd5:8080
复制代码


应用启动速度如闪电般提升至 159ms,仅有 HotSpot VM 的 1/50!


Micronaut 和 Graal VM 还在快速发展中,迁移一个 Spring 应用还有不少工作需要考虑。此外 Graal VM 的调试、监控等工具链还不够完善。但是这已经让我们看到了曙光,Java 应用和 Serverless 的世界不再遥远。由于篇幅有限,对 Graal VM 和 Micronaut 有兴趣的同学可以参考


总结与后记

作为进击的巨人,Java 技术在云原生时代也在不停地进化。在 JDK 8u191 和 JDK 10 之后,JVM 增强了在 在 Docker 容器中对资源的感知。同时社区也在多个不同方向探索 Java 技术栈的边界。JVM OpenJ9 作为传统 VM 的一员,在对现有 Java 应用保持高度兼容的同时,对启动速度和内存占用做了细致的优化,比较适于与现有 Spring 等微服务架构配合使用。


而 Micronaut/Graal VM 则另辟蹊径,通过改变编程模型和编译过程,将应用的动态性尽可能提前到编译时期处理,极大优化了应用启动时间,在 Serverless 领域前景可期。这些设计思路都值得我们借鉴。


在云原生时代,我们要能够在横向的应用开发生命周期中,将开发、交付、运维过程进行有效的分割和重组,提升研发协同效率;并且要能在整个纵向软件技术栈中,在编程模型、应用运行时和基础设施等多层面进行系统优化,实现 radical simplification,提升系统效率。


感谢这个时代,感谢所有帮助和支持我们的小伙伴,感谢所有追梦的技术人,我们一起开拓云原生的未来。


本文转载自公众号阿里巴巴云原生(ID:Alicloudnative)


原文链接


https://mp.weixin.qq.com/s/x509eBHiDuasGmJupJKVow


2019-11-07 08:003305

评论

发布
暂无评论
发现更多内容

6个JDK自带JVM调优工具,一次性打包给你说清楚

田维常

jvm调优

《程序员面试金典》.pdf

田维常

面试

这才是图文并茂:我写了1万多字,就是为了让你了解AQS是怎么运行的

鄙人薛某

Java 并发编程 AQS 并发 ReentrantLock

读完某C++神作,我只记住了100句话

MySQL从删库到跑路

c++

响应式关系数据库处理R2DBC

程序那些事

MySQL R2DBC 程序那些事 响应式系统 响应式数据库

2020双十一,阿里云GRTN拉开直播和RTC技术下半场的序幕

阿里云CloudImagine

架构 云直播 直播 流媒体 直播架构

支撑2715​亿元海量订单 揭秘京东大促背后的数据库基石

京东科技开发者

数据库 数据仓库 云服务 云数据库

.net core增强工作流组件,基于稳定平台,多项目整合开发

雯雯写代码

为什么容器内存占用居高不下,频频 OOM

996小迁

Java 架构 容器 面试 k8s

有点意思的gif动图生成平台开发实战(二)

徐小夕

Java Vue 大前端 GIF React

Vokenization:一种比GPT-3更有常识的视觉语言模型

脑极体

甲方日常 52

句子

工作 随笔杂谈 日常

基于Vue实现一个有点意思的拼拼乐小游戏

徐小夕

Java GitHub 开源 H5游戏 H5

影视剪辑类自媒体运营心得:如何抓住观众的痛点

石头IT视角

SQL数据库集合运算

正向成长

SQL表联结 SQL集合运算

2020年底备战—从技术到面试合集

iOSer

ios 编程 面试

微服务架构中的“参天大树”:SpringBoot+SpringCloud+Docker

小Q

Java 学习 容器 面试 微服务

解读登录双因子认证(MFA)特性背后的TOTP原理

华为云开发者联盟

算法 totp 密钥

厉害了!阿里内部都用的Spring+MyBatis源码手册,实战理论两不误

小Q

Java spring 学习 面试 mybatis

Java中的线程与C++中的区别

jiangling500

Java c++ 线程

这份算法攻略,我拿到了5个大厂的offer

yes

面试 算法 笔试

直播卖货已成趋势

anyRTC开发者

音视频 WebRTC RTC

容器和虚拟机到底有啥区别?

网管

容器 虚拟机

go-zero 如何扛住流量冲击(一)

万俊峰Kevin

microservice go-zero goctl Go 语言

超越竞争文化:致善式创新能否打造手机产业的“海法城”

脑极体

程序员如何判断跳槽岗位是否有坑!

Java架构师迁哥

区块链数字货币商城系统开发模式

薇電13242772558

区块链 数字货币

【JVM】肝了一周,吐血整理出这份超硬核的JVM笔记(升级版)!!

冰河

性能优化 内存模型 JVM 堆栈 JVM笔记

什么是服务器租用?

德胜网络-阳

Java中NullPointerException的完美解决方案

Silently9527

java8 Optional

SpringBoot-技术专题-Hystrix学习介绍

码界西柚

进击的 Java ,云原生时代的蜕变_语言 & 开发_阿里云容器平台_InfoQ精选文章