如何进行基于Anolis OS的企业级Java应用规模化实践？

Alibaba Dragonwell 是一款 OpenJDK 的发行版。OpenAnolis 是企业级的操作系统，企业级操作系统必然包含企业级应用的运行时。众所周知，红帽的 CentOS 发行版里面其实有红帽自己做的 JDK 发行版，这既是他们对自己运行时技术可控的自信，也是对用户负责，比如说 OpenJDK 出现任何问题，他们可以在发行版上做改动，去帮助用户解决问题。
Java 企业应用
Java 一直是企业级最佳的选择，其中有很多原因，目前云原生环境下，它有非常成熟的容器化方案，有 Spring boot 这样的框架来帮助我们把应用打包成一个非常适合容器运行的模式。也有很多分布式的中间件，比如说 Spring cloud，可以帮助我们构造分布式应用。Java 也有非常好的规范以及开源生态，Oracle 虽然控制着 Java，同时也推进着 Java 标准往前演进，标准使得语言一直是可以控制的方向发展，非常适合开发企业级应用。里面有非常繁荣的生态，比如 Maven 可以帮助开发者快速获得开发依赖，还有 Netty、Tomcat、Spring。虽然 Spring 可以看做是挑战 Jakarta EE 的角色，但是它本身也受到 Java 的很多影响，因此可以说是 Jakarta EE 也在帮助 Spring 发展。
高效，运行时的高效和开发时的高效。运行时的高效体现在 Java 的执行速度，一个数据是 Java 的运行效率可以排在各大编程语言第四，效率可以达到 C 语言的二分之一，这在高级语言里非常难得的。
最后是行业实践，在互联网金融等行业里大规模使用 Java。

大家认为硬件+操作系统+应用就构成整个应用，其实运行时对于应用的运行影响是非常大的，通过一个例子解释。
这是我们在企业客户里遇到的一个问题，在 Java 运行时开始很好，经过一天以后性能就变成 1/2，越来越慢，只能选取变慢的实例重启或者是扩容，因为变慢后需要更多的机器支撑容量。但这并不解决问题，因为变慢这个行为持续在发生。
最后排查出是 JIT 相关问题， Java 应用有 JIT 编译器，也有解释模式，我可以给大家一个数字，编译模式要比解释模式快 50 倍左右，所以有部分代码执行在解释模式的话，影响非常大，假如有 2% 的代码在解释器模式，则整个应用一半的时间在执行解释器，一半的时间在执行编译器，性能下降一倍。假如说一半的代码退到解释器，那应用就会慢 25 倍左右，所以运行时对应用有深远影响。
阿里巴巴 Dragonwell 和 Eclipse Temurin 都是 OpenJDK 的开源发行版本，为什么近年来除了谷歌以外所有的头部云厂商都推出了自己的发行版。自 OpenJDK9 开始，每半年发布一个版本，这个版本只会维护一年，比如说 OpenJDK 从 2018 年 3 月开始维护到 2019 年 3 月，中间只有一年的维护时间，选取这样的策略是因为 OpenJDK9 引入了很多新的特性，比如说模块化，对开发进程影响非常大，所以选取了这样一种滚动升级策略。
假如我们的用户想去使用最新的 JDK，那他必须接受滚动升级。比如说现在 Java 已经到了 17 了，五年后 Java 会到达 27 的版本，这样的升级频率肯定是接受不了的。假设 Java 用户停留在老版本是不是可以避免这种滚动升级？实际也不行， Java 远程执行漏洞非常多，我们可以通过序列化构造一些远程代码执行的例子，这是非常可怕的。各个云厂商都提供了自己的 OpenJDK 发行版，想获得 Oracle 也是可以的，是收费的。
阿里巴巴 Dragonwell 就是在这种背景下产生出了 Java 运行时，我们完全依托开源社区建设，我们参与了非常多国际上的高质量社区，现在也加入了龙蜥社区，其中包括 Java 的 JCP-EC，阿里巴巴是国内唯一一个加入 EC 席位的企业(EC的全称是执行委员会)。

Alibaba Dragonwell 是在 OpenJDK 的基础上增加了一些自己的功能，构成了阿里巴巴 Dragonwell 发行版本。我们会发布稳定的发行版本，并且提供定期的安全补丁，质量体系接轨国际，基于 Adoptium 的 CI，Adoptium 组织由各个 JDK 的头部厂商维护，包括微软、IBM 都参与其中。经过测试以后，我们会在阿里巴巴线上验证；SVT 系统验证，会用 spring 等常用框架进行验证我们的 JDK。我们也支持多平台，比如Linux、windows、RISC-V 架构的支持也已经提上日程。

和Java企业计算相关的另外一个发行版是Eclipse Temurin，它源自AdoptOpenJDK。AdoptOpenJDK 是怎么来的？可以看到前面的 Oracle 发布策略，大家使用 OpenJDK 会越来越困难，所以伦敦的 Java User Group 创建 AdoptOpenJDK 项目，让 OpenJDK 可以方便地被用户使用。该项目编译 OpenJDK 的 source code，经过 aqa-tests 才会 release 出来，可以说是原汁原味的 OpenJDK。和 Alibaba Dragonwell 的差异是：上一页有一块 Dragonwell 补丁，而 Temurin 是原汁原味的 OpenJDK。

Aqa-tests 包括性能测试，OpenJDK 自带测试。其中的 system 测试会验证 Java 的模块化系统，Java 的自带工具等。后面是 external，包括 Java 生态里面常见的一些软件，像 scala、kafka。最后是标准的 JCK，Oracle 所颁布的一个标准，只要 JDK 发行版跑过验证就是标准的 JDK。

很多传统企业用户不需要阿里巴巴 Dragonwell 里面为云或者互联网设计的功能，他可以选择 Eclipse Temurin 发行版。

让我们看看使用这两个发行版企业可以获得什么：

1、安全特性，Java 的 TSL 能力是通过 JSSE 接口使用的，Eclipse Temurin 和Alibaba Dragonwell 的 JSSE 能力都会经过验证，这对企业用户是非常重要的。
2、兼容性，Dragonwell 基于 OpenJDK 而 Temurin 是原汁原味的 OpenJDK，从 OracleJDK 迁移到 OpenJDK 可以保证兼容性。
3、Java 生态的集成验证。
4、定期安全补丁，Alibaba Dragonwell 或者 Eclipse Temurin，这两个发行版是完全以完全开源的形式运作的。我们会以每三个月一次的固定发行周期提供订阅支持。
Alibaba Dragonwell 上有很多阿里巴巴自己扩展的云原生特性，通过这些特性我们可以轻易的排查问题或者轻易的减少资源使用，或者是降低总体成本，这是 Eclipse Temurin 和 OracleJDK 所没有的。

基于这两个 JDK 发行版本我们提供了企业服务体系。如果企业用户从 OracleJDK 某个版本迁移过来，首先面临的问题是迁移。Java 的版本迁移不像 GO 或者其他语言那样轻松，比如 JDK8 迁移到 11 或者 17，都有很大的迁移工作量。我们提供迁移了工具，并积累了许多迁移经验文档给到企业去迁移到 Eclipse Temurin 或者 Alibaba Dragonwell。

Java 由于庞大的类库会隐含很多的安全问题。如果选择订阅了 Alibaba Dragonwell 企业支持服务，会获得每三个月的推送，对于一些重大更新我们会进行评估，是否是重要更新，是否要升级，升级计划是什么。

应急支撑体系是 IT 企业的日常需求，在 Java 使用中只要上了规模都会有无法预期的问题。这里我们提供了 7×24 小时的专属钉钉或者电话支持，响应时间保证到在业务不可用情况下 10 分钟响应，业务一般的问题在一小时可以获得响应，主要城市可以两小时内得到到达现场的服务。

我们结合之前的案例来看，用户通过我们的服务能获得怎样的体验。首先用户发现并报告了问题，由于北京是主要城市，两小时内可以到达现场。随后我们帮助用户保存现场，分析问题，定位问题，最后交付服务。

代码空间满导致代码部分解释执行，从而性能变差，但代码空间满依旧不是根因。一步步深入定位，分析出原因：因为用户从低版本 JDK 升上来，低版本 JDK 的代码回收功能是有问题的，因此用户禁用了代码空间的回收功能。随着应用持续运行，编译代码越来越多，如果开启了代码空间的回收，失效代码是可以被 Java 虚拟机回收的。但是用户关闭了代码空间回收，最终导致代码空间满。Hotspot 虚拟机在代码空间满时策略是禁止 JIT 编译。

确认问题后帮助用户在少量机器上验证，确认修复完成后交付服务，书面给与用户确认。

这就是基于 OpenAnolis 的 Java 企业计算。