苹果|如何进行基于 Anolis OS 的企业级 Java 应用规模化实践？( 二 ) Mini LED

假如我们的用户想去使用最新的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发行版。

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

【苹果|如何进行基于 Anolis OS 的企业级 Java 应用规模化实践？】
安全特性， Java的TSL能力是通过JSSE接口使用的， Eclipse Temurin和Alibaba Dragonwell的JSSE能力都会经过验证，这对企业用户是非常重要的兼容性， Dragonwell基于OpenJDK而Temurin是原汁原味的OpenJDK ，从OracleJDK迁移到OpenJDK可以保证兼容性。Java生态的集成验证定期安全补丁， 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编译。确认问题后帮助用户在少量机器上验证，确认修复完成后交付服务，书面给与用户确认。原文链接：http://click.aliyun.com/m/1000316787/ 本文为阿里云原创内容，未经允许不得转载。