文中前半部分截取、参照、截取了周志明《Graal VM 云原生时代的Java》视频讲解公开的PPT的部分内容，特此声明，在此对周志明精彩的分享表示感谢。
云原生的核心是什么？
技术人员谈技术问题直接、要看本质，不能东拉西扯。现在很多厂商都在谈云原生应用，那么云原生应用的核心是什么？
云原生的应用开发框架。
提到开发框架。传统的Java系的应用开发框架比较著名的是SSH（Spring框架、Hibernate框架、Struts框架）。
Spring MVC是基于 Servlet 的一个 MVC 框架 主要解决 WEB 开发的问题，因为 Spring 的配置非常复杂，各种XML、 JavaConfig、hin处理起来比较繁琐。于是为了简化开发者的使用，从而创造性地推出了Spring boot，约定优于配置，简化了spring的配置流程。
现有的绝大多数企业级应用都是由Java开发的。Java的特点如下：
![]()
所以说，Java通过众多的规范（JSR），让应用开发人员遵从，这有助于提升应用的规模、稳定性。
在微服务时代，传统Java的理念与时代产生了巨大的矛盾。
![]()
随着Web应用的发展，微服务时代，应用的稳定性不再依赖于单个单体应用实例的稳定性，而是借助于应用集群、K8S等技术保证应用的高可用性。好比传统应用是宠物，微服务是牛羊。微服务更关注与单个应用实例是否消耗资源，启动速度是否快。
在微服务时代，如果我们只是将应用运行的“底座”由Linux换成容器，如下图所示，那效果就会比较尴尬（例如在容器中运行weblogic，承载应用），这不是成不成的问题，而是效果好不好的问题。
![]()
那么问题的根源是什么呢？
还是由Java本身的特点决定的。Java的解释型语言，解释型语言就需要解释器，JVM。而JVM是相当耗费内存的，并且启动也慢。
此外，Java的代码域是动态的。常用到的Java动态特性主要是反射，在运行时查找对象属性、方法，修改作用域，通过方法名称调用方法等。这样做的好处是，Java 程序可以加载一个运行时才得知名称的 .class 文件，然后获悉其完整构造，并生成其对象实体、或对其 fields（变量）设值、或调用其 methods（方法）。
解决Java问题的方法
Oracle当然也意识到Java在微服务时代的尴尬之处，因此在前两年推出了新一代JVM：GraalVM。
GraalVM是一款高性能的可嵌入式多语言虚拟机，它能运行不同的编程语言，包括：
基于JVM的语言，比如Java, Scala, Kotlin和Groovy
解释型语言，比如JavaScript, Ruby, R和Python
LLVM支持的原生语言，比如C， C++， Rust和Swift
GraalVM中包含Graal Compiler编译器。Graal Compiler是GraalVM与HotSpotVM（从JDK10起）共同拥有的服务端即时编译器，是C2编译器未来的替代者。
![]()
Graal Compiler支持提前编译（AOT）和即时编译（JIT）。
两者的优缺点对比如下表所示：
![]()
总结起来，AOT编译后，应用包更小、消耗内存更少、启动速度更快。JIT编译的应用，吞吐量更高、延迟更低。
![]()
此外，我们知道，HotSpotVM是JVM标准的技术实现。HotSpotVM是Sun JDK和OpenJDK中自带的JCM，使用很广。而Substrate VM是一个框架，可以将Java程序编译为独立的可执行文件，它的架构如下图所示。对于GraalVM而言，HotSpotVM是可选的：
![]()
接下来，我们再看一下GraalVM的版本。Oracle推出了社区版本（CE）和企业版（EE），两者区别如下图所示：
![]()
截止到目前，我们已经清楚了针对Java不适用于微服务，Oracle的做法，就是通过GraalVM实现本地编译，从而甩来HotSpot。
那么，针对Java不适用于微服务的现状，让我们跳出Java圈，IT圈的大佬们是想如何解决的呢？
解决问题的流派
解决问题的方法大致有如下几种：
![]()
在上图中，后两种主要是更为靠谱的。
至于采取第二种还是第三种，那不同的厂商显然会有自己的思路。
从技术角度看：传统的Java应用改造成GraalVM Native还是有难度的。
Quarkus是红帽主导发布的新一代云原生Java。Quarkus确实面临重新书写应用的问题。从红帽的角度，传统的应用与其向GraalVM Native迁移，不如向基于K8S的轻量级应用服务器JBoss EAP迁移更为靠谱（后面也会给出介绍）。
Quarkus红帽在2020年正式GA（开源项目去年发布），目前github上有5000个Star，还算不错。
![]()
Quarkus的框架
Quarkus的框架如下，
![]()
由于Quarkus依赖GraalVM CE，而GraalVM CE是由Oracle发布的。因此红帽发布了GraalVM CE的下游社区：Mandrel。通过Mandrel红帽将GraalVM特性集成在在Red Hat Enterprise Linux和OpenJDK 11发行版上，以便红帽可以对此提供企业级支持。
Quarkus的一个特点是包含很多扩展。Quarkers 的扩展是一组依赖项，可以将它们添加到 Quarkus 项目中，从而获得特定的功能，例如健康检查等。扩展将配置或引导框架或技术集成到 Quarkus 应用程序中。通过命令行可以列出 Quarkers 可用和支持的扩展：
![]()
此外，Quarkus还有个优势是：支持热加载。即以开发模式启动应用后，修改应用源代码无需重新编译和重新运行，应用而直接生效。如果是 web 应用，在前台刷新浏览器即可看到更新结果。Quarkus 的开发模式非常适合应用调试阶段、经常需要调整源码并验证效果的需求。
Quarkus还可以和Kafka对接（后面其他文章会介绍）。
Quarkus具体的实战内容，可以参照笔者在IBM官网发表的文章：
https://www.ibm.com/developerworks/cn/cloud/library/cl-lo-quarkus-supersonic-subatomic-java-experience/index.html
根据IDC在2020年5月份发布的数据，Quarkus Native比其他框架节约64%的云资源。如果运行在JVM模式，可以节约37%的资源。
![]()
Quarkus Native运行只需要21M内存
![]()
在基于AWS部署的OpenShift4.2上运行10个pod，消耗内存的对比：
![]()
吞吐量对比：
![]()
实例扩容所需时间对比：
![]()
启动时间对比：
![]()
GraalVM的限制
GraalVM的限制如下链接所示：有的需要配置才能实现，因此在开发时应注意这些限制。
https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
Dynamic Class Loading / Unloading
Runtime Bytecode Generation *
InvokeDynamic Bytecode and Method Handles
Finalizers
Serialization
Security Manager
JVMTI、JVMCI，other native VM interfaces
传统应用向JBoss EAP迁移的步骤
针对客户现有的运行在传统应用服务器上（如WebLogic）的应用，如何迁移到JBossEAP上呢？我们可以借助Red Hat Application MigrationToolkit（简称：RHAMT）
RHAMT是开放源代码工具的组合，可实现大规模的应用程序迁移和现代化。该工具由多个单独的组件组成，这些组件为迁移过程的每个阶段提供支持。支持的迁移包括应用程序平台升级、向云原生部署环境的迁移、以及从几种商业应用服务器到JBoss EAP的迁移。
RHAMT提供三种软件包下载：
COMMAND LINETOOLING：命令行界面提供了一个高级界面，用于以自动化方式对许多应用程序进行批处理分析。该界面可以提供详细的评估报告，这些报告可以纳入对应用程序的完整评估中，以便进行优先级排序和规划。
WEB CONSOLE：Web控制台提供简化的界面，用于管理大量应用程序以进行评估和分析。使用此工具，用户可以管理大量应用程序，以便有效地确定优先级并计划要迁移的应用程序，并评估每次迁移所涉及的难度。
IDE TOOLING：IDE插件为开发人员提供了交互式的实施时间帮助。通过提供内联帮助以及使迁移和现代化过程中的复杂步骤自动化的全自动快速修复程序，这简化了应用程序的迁移过程。
我们查看工具下载界面（https://developers.redhat.com/products/rhamt/download），
我们先下载CLI工具。安装CLI工具的系统需要安装JavaSE Development Kit（JDK）版本8，我们建议使用OpenJDK或OracleJDK。
安装RHAMTCLI工具很简单，直接解压缩即可：
# unzipmigrationtoolkit-rhamt-cli-4.3.1-offline.zip
接下来，我们展示如何运行CLI来分析示例WebLogic应用程序，以识别将其迁移到JBossEAP 7所需的更改。示例程序为：simple-sample-app.ear（下载地址为：https://github.com/ocp-msa-devops/RHAMT.git）
执行如下命令：
# ./rhamt-cli-4.3.1.Final/bin/rhamt-cli--input ./simple-sample-app.ear --output --source weblogic --target eap:7--packages com.acme
此命令使用以下选项：
--input：要分析的应用程序的路径。
--output：生成的报告的输出目录。
--source：应用程序的源技术。
--target：用于应用程序迁移的目标技术。
--packages：要评估的软件包列表。
命令执行结果如图显示的名为index.html的评估报告。
![]()
针对报告指出的问题进行调整：
![]()
将报告提示的问题点修改完毕后，再次运行报告，确保story points为0
![]()
源码修改成功后，重新打包应用，然后使用OpenShift上的JBoss EAP Builder Image进行应用容器化即可。
结论
针对云原生Java这个话题，红帽推荐的方案是Quarkus。Quarkus可以运行在Hospot或GraalVM上。至于选择哪种，需要参照GraalVM自身的限制。Quarkus+GraalVM+AOT是应用所需资源最少、启动最快的方式。
针对传统的应用，既可以迁移到轻量级的应用服务器如EAP上，也可以将遗留代码升级成GraalVMNative应用。这两种方法都可以，这取决于客户传统应用的复杂度和规划。
参考文档:
https://developers.redhat.com/blog/2020/06/05/mandrel-a-community-distribution-of-graalvm-for-the-red-hat-build-of-quarkus/
