【Quarkus技术系列】「序章」打造基于Quarkus的云原生微服务框架实践的理论知识基础

前提介绍

本系列文章主要讲解如何基于Quarkus技术搭建和开发“专为Kubernetes而优化的Java微服务框架”的入门和实践,你将会学习到如何搭建Quarkus微服务脚环境及脚手架,开发Quarkus的端点服务,系统和应用层级的配置介绍与Quarkus的编程模型分析,创建Quarkus的应用Uber-jar文件以及集成到Kubernetes的环境中。

  1. 学习Quarkus的云原生微服务的零基础搭建和开发实践
  2. 分析Quarkus的编程模型以及与Kubernetes环境进行集成

面向的人群

Java软件开发人员、系统架构师、微服务开发爱好者、运维部署人员等。

目前的状况

近几年由于云原生技术的普及,越来越多的用户开始使用容器来运行微服务应用,随着微服务的快速发展,spring全家桶已然成为了java框架的事实标准,包括单体应用使用的spring Framework和springboot,微服务间服务治理框架spring cloud,生态系统完善,各种组件层出不穷。

Java云原生化痛点

  • 轻量化容器技术的诞生促使JVM服务变得更加臃肿

    • 微服务架构的引入,使我们的服务颗粒度变得越来越小,轻量且能快速启动的应用能够更好的适应容器化环境。 以我们目前常规的Spring Boot应用来说,一般Restful服务的jar包大概是30M左右,如果我们将JDK以及相关应用打包成docker镜像文件大概是140M左右。

    • 常规的Go语言的可执行程序生成镜像包一般不会超过50M。如何让臃肿的Java应用瘦身使他易于容器化,成为Java应用云原生化需要解决的问题。

  • 轻量化容器技术的诞生促使JVM服务内容使用量变得过大

    • JVM对于内存的使用量变的越来越大,会促使FullGC的过多甚至OOM。
  • SpringBoot的微服务应用启动的速度越来越慢(JVM启动速度)

    • 从JVM启动到真的应用程序执行需要经历VM加载,字节码文件加载,以及JVM为了提升效率,借助JIT(just in time)及时编译技术对解释执行的字节码进行局部优化,通过编译器生成本地执行代码的过程,同时还需要加上了JVM内部垃圾回收所耗费的时间。
      【Quarkus技术系列】「序章」打造基于Quarkus的云原生微服务框架实践的理论知识基础_第1张图片

典型的Java应用加载时间一般都是秒级起步,如果遇到比较大的应用初始花费几分钟都是正常的。 以往由于我们很少重新启动Java应用,Java应用启动时间长的问题一般很少暴露出来。

  • 但是在云原生应用场景下,随着粒度变的非常细,所以导致部署频率过于频繁

    • 我们会经常不断重启应用来实现滚动升级或者无服务应用场景。 Java应用启动时间长的问题就变成了Java应用云原生化亟待解决的问题。

Quarkus的介绍

  • Quarkus定位为GraalVM和OpenJDK HotSpot量身定制的Kubernetes Native Java框架。

  • Quarkus是红帽开源的项目,借助开源社区的力量,通过对业界广泛使用的框架进行了适配,并结合云原生应用的特点,提供了一套端到端的Java云原生应用解决方案。

  • 虽然开源时间较短,但是生态方面也已经达到可用的状态,自身包含扩展框架,已经支持像Netty、Undertow、Hibernate、JWT等框架,足以用于开发企业级应用,用户也可以基于扩展框架自行扩展。

【Quarkus技术系列】「序章」打造基于Quarkus的云原生微服务框架实践的理论知识基础_第2张图片

向原生迈进

对需要长时间运行的应用来说,由于经过充分预热,热点代码会被HotSpot的探测机制准确定位捕获,并将其编译为物理硬件可直接执行的机器码,在这类应用中Java的运行效率很大程度上是取决于即时编译器所输出的代码质量。

HotSpot虚拟机中包含有两个即时编译器,分别是编译时间较短但输出代码优化程度较低的客户端编译器(简称为C1)以及编译耗时长但输出代码优化质量也更高的服务端编译器(简称为C2),通常它们会在分层编译机制下与解释器互相配合来共同构成HotSpot虚拟机的执行子系统的。

【Quarkus技术系列】「序章」打造基于Quarkus的云原生微服务框架实践的理论知识基础_第3张图片

新一代即时编译器(Graal VM)

自JDK 10起,HotSpot中又加入了一个全新的即时编译器:Graal编译器,看名字就可以联想到它是来自于前一节提到的Graal VM,Graal编译器是作为C2编译器替代者的角色登场的。

C2编译器的问题

C2的历史已经非常长了,可以追溯到Cliff Click大神读博士期间的作品,这个由C++写成的编译器尽管目前依然效果拔群,但已经复杂到连Cliff Click本人都不愿意继续维护的程度。

Graal编译器本身就是由Java语言写成,实现时又刻意与C2采用了同一种名为“Sea-of-Nodes”的高级中间表示(High IR)形式,使其能够更容易借鉴C2的优点。

Graal编译器比C2编译器晚了足足二十年面世,有着极其充沛的后发优势,在保持能输出相近质量的编译代码的同时,开发效率和扩展性上都要显著优于C2编译器,这决定了C2编译器中优秀的代码优化技术可以轻易地移植到Graal编译器上,但是反过来Graal编译器中行之有效的优化在C2编译器里实现起来则异常艰难。

Graal编译器

Graal的编译效果短短几年间迅速追平了C2,甚至某些测试项中开始逐渐反超C2编译器。

Graal能够做比C2更加复杂的优化,如“部分逃逸分析”(Partial Escape Analysis),也拥有比C2更容易使用“激进预测性优化”(Aggressive Speculative Optimization)的策略,支持自定义的预测性假设等等。

【Quarkus技术系列】「序章」打造基于Quarkus的云原生微服务框架实践的理论知识基础_第4张图片

Graal编译器尚且年幼,还未经过足够多的实践验证,所以仍然带着“实验状态”的标签,需要用开关参数去激活,这让笔者不禁联想起JDK 1.3时代,HotSpot虚拟机刚刚横空出世时的场景,同样也是需要用开关激活,也是作为Classic虚拟机的替代品的一段历史。

Graal编译器未来的前途可期,作为Java虚拟机执行代码的最新引擎,它的持续改进,会同时为HotSpot与Graal VM注入更快更强的驱动力。

【Quarkus技术系列】「序章」打造基于Quarkus的云原生微服务框架实践的理论知识基础_第5张图片

GraalVM的总结分析

GraalVM:JVM为了提升效率,借助JIT及时编译技术对解释执行的字节码进行局部优化,通过编译器生成本地执行代码提升应用执行效率。

GraalVM是Oracle实验室开发的新一代的面向多种语言的JVM即时编译器,在性能以及多语言互操作性上有比较好的表现。与Java HotSpot VM相比,Graal借助内联,逃逸分析以及推出优化技术可以提升2至5倍的性能提升。

GraalVM提供的静态编译功能,只能针对其编译时能够看得的封闭世界进行优化,对于那些使用了反射、动态加载、以及动态代理的代码是无能为力的。

  • 为了能让我们日常的Java应用能够正常运行起来,需要我们对应用所使用到的框架和类库进行相关修改适配。

  • 由于Java代码所使用的类库很多,这部分的工作量还是相当巨大的,虽然GraalVM已经推出超过一年多的时间,但是还是很少见到大规模Java应用转移到这个平台之上。

你可能感兴趣的:(微服务,云原生,java)