【Quarkus技术系列】打造基于Quarkus的云原生微服务框架实践（1）

前提介绍

本系列文章主要讲解如何基于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内部垃圾回收所耗费的时间。

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

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

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

Quarkus的介绍

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

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

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

向原生迈进

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

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

新一代即时编译器（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）的策略，支持自定义的预测性假设等等。

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

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

GraalVM的总结分析

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

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

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

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

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