导读：
在万物云原生下的环境下，Java 的市场份额也因耗资源、启动慢等毛病，导致在云原生环境里被放大而升高，通过这篇文章，读者能够更好地理解如何在云原生环境下通过降级相干版本和应用 GraalVM 打出原生镜像到形式，优化 Java 利用的性能和资源利用率，使 Java 利用更好地适应云原生环境。
1. 引言（Introduction）
1.1、目标：
当初咱们的我的项目能失常运行，为什么要消耗大量人力重构？
1.2、背景：
云原生时代下和 java 的爱恨情仇：
在云原生时代，随着技术的突飞猛进变动，咱们寻找最佳技术解决方案的路线上总是充斥崎岖。作为分布式应用的支流技术，Kubernetes（简称 k8s）和 Java 在这个时代交错出一段爱恨情仇般的佳话。那云原生下这两个技术到底是敌是友，须要咱们进行深入分析。首先，咱们站在云原生的角度来看，难以漠视的是 k8s 确实被时代认可，尤其在微服务架构、容器化部署和资源管理等方面。其弱小的自动化、弹性伸缩和容错能力成为了很多软件系统的最佳实际。而 Java 作为一门领有 28 多年历史的编程语言，无论是在市场份额和生态圈都有无可撼动的位置。Java 在分布式系统、中间件、业务逻辑解决等方面有着丰盛的实践经验，为开发人员提供了良好的编程体验和广大的生态反对。而在泛滥利用架构的背地的技术架构都离不开 Kubernetes 和 Java。从这个角度看来，它们仿佛是一对黄金搭档，但关系到具体实际过程时，细节往往能决定成败。咱们来看看这两个技术在实际操作中产生的爱恨情仇。
1.2.1、爱与恨：资源限度与治理
在云原生架构中，k8s 为利用提供了资源限度与治理的能力，使得利用可能按需分配资源。然而，Java 在解决资源方面存在肯定的局限性。因为 JVM 在内存治理方面依赖于 Xms 和 Xmx 等参数进行配置，导致利用在 Kubernetes 中的资源管理绝对简单。在这期间咱们发现 java 也不甘示弱 在 JVM 层面对资源管理等方面也进行了改良 比方减少了 Containters 标记，使得 Java 利用在 k8s 环境中的资源配置更为简化。
1.2.2、恩怨难分：服务发现与负载平衡
在微服务架构中，服务发现和负载平衡是要害。过来，Java 生态中有很多解决方案，例如 Eureka、Zookeeper 等，这让 java 在服务发现和负载平衡方面有多种抉择，
但在 k8s 环境中，人造具备服务发现和负载平衡的能力，如果须要转到云原生就须要对微服务进行调整以适配 k8s 环境。
1.2.3、重逢：继续集成与继续部署（CI/CD）
k8s 在继续集成与继续部署方面具备很强的能力，与 GitLab、Jenkins 等 CI/CD 工具的联合能够为 Java 利用提供极致的开发、构建和部署体验。通过将 k8s 和 Java 生态中优良的 CI/CD 工具整合在一起，架构师可能实现麻利的开发、疾速的迭代和高效的运维。
1.2.4、共生：爱恨交织
在 k8s 的世界里，Java 应用程序的部署和治理未然变得越来越高效。但随着微服务、Serverless 架构的衰亡，Java 的致命缺点开始裸露进去。首先是启动工夫，Java 应用程序在启动时须要加载泛滥类文件，带来了绝对较长的启动工夫。再者，Java 应用程序的内存占用往往较高，这在云原生环境中意味着更高的运行老本。而后咱们开始寻找代替计划，以求解脱 Java 在云原生畛域的解放，进而拥抱更快、更轻量级的利用程序运行环境。
1.2.5、曙光：已经失去的通通要拿回来
于是，GraalVM 应运而生。GraalVM 是一个高性能的 Runtime，反对多种编程语言（这也是它通用的起因）。它提供了 Java 与云原生畛域的桥梁，能够将 Java 代码编译成本地可执行文件，这意味着更快的启动速度和更低的内存应用。与之同时，GraalVM 还提供了对 Java 的残缺反对，便于将现有的 Java 应用程序迁徙到云原生畛域。此外，GraalVM 还集成了许多弱小的个性，如 (AOT) 编译、即时编译（JIT）以及弱小的 GC 回收机制。这些个性使得 GraalVM 成为了在云原生畛域的新宠。
2、技术选型：
2.1、五因素：
2.1.1、充分利用现有代码库：
如果曾经领有一个性能齐备且通过充沛测试的 Java 应用程序，那么将其转换为 native-image 能够最大水平地复用现有代码库，缩小从新编写应用程序所需的工作量和危险。此外咱们部门我的项目都是 Java，应用 native-image 能无效升高迁徙老本。
2.1.2、开发者相熟度：
如果队伍中曾经具备较为丰盛的 Java 开发教训，那么将 Java 利用转换为 native-image 会升高学习老本和培训老本，相较于应用全新的编程语言来重写利用，这会使得开发者更容易上手。
2.1.3、性能优化：
尽管 Java 利用在某些性能方面可能不如其余编程语言，但通过应用 native-image，能够将 Java 利用转换为与 C 或 C ++ 等编译型语言相似的二进制文件，从而放大性能差距。native-image 为利用带来更快的启动速度和更低的内存占用，而这在 k8s 这种容器化的环境中尤为重要。
2.1.4、跨平台能力：
Java 具备良好的跨平台兼容性，而借助 GraalVM 进行 native-image 编译，咱们仍然能够保留这一个性。这为利用部署提供较高的灵活性，升高了环境迁徙和保护的复杂度。
2.1.5、开发和生态系统：
Java 领有宏大的开发社区和一个成熟、丰盛的生态系统，提供了大量的库和框架来反对各种利用的开发。应用 native-image 能够更好地利用这些资源，简化利用的开发和保护过程。
2.1.6、最终计划：
采纳 jdk17+springboot3+native-iamge= 原生轻量化服务
对于低频流量的业务零碎，采纳试点我的项目的形式保障可行性的落地，依据业务性能进行我的项目合并，而对于合并后的全新我的项目，间接降级 (jdk 和 spring 框架) version 实现我的项目合并后保障 java 版本的我的项目跑起来，之后采纳 native-image 的形式打包成原生镜像，让我的项目在 新个性 / 稳定性的版本根底上 晋升为真正的轻量化利用。
3、概念：
3.1、为什么要降级 jdk？
3.1.1、新的语言个性 ：
JDK 8 到 JDK 17 之间引入了许多新的语言个性和性能，如 Lambda 表达式、Stream API、Optional 类、默认办法、接口公有办法等。这些个性能够使代码更简洁、可读性更好，并反对函数式编程格调，进步开发效率和代码品质。
3.1.2、性能优化和加强：
JDK 17 中进行了多项性能优化和加强，包含垃圾回收器的改良、JIT 编译器的加强、并发类库的改良等。这些优化能够进步应用程序的性能和吞吐量，特地是在大规模和高并发的状况下。
3.1.3、模块化零碎：
JDK 9 引入了模块化零碎（Java Platform Module System，JPMS），它提供了更好的代码组织和隔离，使得简单的应用程序能够更容易地保护和扩大。模块化零碎还能够帮忙辨认和解决潜在的依赖抵触问题，进步应用程序的稳定性和可靠性。
3.1.4、安全性加强 ：
JDK 17 在安全性方面有多项改良，包含增强的加密算法（SHA-3、X25519、Ed25519）、更新的平安协定（TLS 1.3）、安全性加强的 API 等。这些改良能够晋升应用程序的安全性，防备潜在的安全漏洞和攻打。
3.1.5、工具和性能剖析：
JDK 17 提供了许多工具和性能剖析的改良，例如 JShell（交互式编程工具）、Java Flight Recorder（JFR，低开销的性能剖析工具）、JDK Mission Control（JMC，性能监控和故障诊断工具）等。这些工具能够帮忙架构师和开发团队更好地剖析和优化应用程序的性能和行为。
3.1.6、继续改良和稳定性：
从 JDK 8 到 JDK 17，Java 平台始终在继续改良和演进。JDK 17 是一个长期反对（LTS）版本，意味着它将取得长期的反对和保护，包含安全更新、谬误修复和性能改良。作为架构师，抉择降级到 JDK 17 能够取得更稳固和牢靠的平台，并确保应用程序可能失去长期的反对。
3.2、为什么要降级 springboot 组件？
3.2.1、充分利用 JDK 17 的新性能和性能优化：
JDK 17 引入了许多新的性能、改良和性能优化。这些包含新的语言个性、加强的性能和安全性、更好的垃圾回收器、模块化零碎等。通过将 Spring Boot 降级到版本 3，能够利用 JDK 17 的新性能，进步应用程序的性能、稳定性和安全性。
3.2.2、反对新的 Java 版本：
Spring Boot 1.x 系列最后是为 JDK 6 和 JDK 7 开发的，而 Spring Boot 2.x 系列则对 JDK 8 有更好的反对。咱们将 JDK8 降级到 JDK 17，将 Spring Boot 从版本 1.x、2.x 降级到版本 3，能够确保应用程序可能充分利用 JDK 17 的新个性，并取得更好的兼容性和性能。
3.2.3、修复已知的问题和破绽：
随着工夫的推移，Spring Boot 的新版本会修复旧版本中存在的问题、破绽和谬误。通过降级到最新的 Spring Boot 版本，您能够取得这些修复，并进步应用程序的稳定性和安全性。
3.2.4、社区反对和文档更新：
随着工夫的推移，Spring Boot 社区会随着新版本的公布而更新和改良文档、示例和社区反对。通过降级到最新版本，您能够取得最新的文档和社区反对，使您可能更好地应用和保护 Spring Boot 应用程序。
3.3、降级 jdk/springboot 可能导致的差别？
3.3.1、API 变动：
JDK 在不同的版本中引入了新的 API，并对旧 API 进行了批改和弃用。在降级到 JDK 17 之前，须要仔细检查你的代码，查找并解决所有应用了已弃用的 API 的中央。还应该相熟 JDK 9、JDK 11、JDK 14 和 JDK 17 之间的次要 API 变动，以便在降级过程中进行必要的批改（servlet api 没报错先疏忽）。
3.3.2、模块化零碎（Module System）：
1.JDK 9 引入了模块化零碎，将 JDK 中的性能划分为一组模块。如果你的应用程序依赖于 JDK 8 中不存在的模块，或者应用了模块化零碎中的新个性（如模块门路），在降级到 JDK 17 时须要进行相应的调整。确保你的应用程序的模块申明和依赖关系与 JDK 17 兼容，并进行必要的迁徙工作（jdk8 升的疏忽）。
3.3.3、移除的性能：
JDK 8 到 JDK 17 期间，JDK 团队可能会移除一些不再反对的性能。在降级之前，查看 JDK 的公布阐明和文档，理解哪些性能将被移除或弃用。查看你的代码是否应用了这些性能，以便及时进行批改和适应。
3.3.4、字节码和运行时差别：
JDK 17 中引入了一些新的字节码指令和运行时优化，这可能会导致你的应用程序在降级后呈现不同的行为。特地是在应用反射、字节码加强和动静代理等技术的状况下，须要认真测试和验证降级后的应用程序是否依然失常运行。
3.3.5、第三方库和工具兼容性：
降级 JDK 可能会对你的应用程序依赖的第三方库和工具产生影响。在进行降级之前，确保你所应用的所有库和工具与 JDK 17 兼容，并及时更新到最新版本。此外，还要注意一些特定的库或工具可能会有与 JDK 版本相干的限度或要求。
3.3.6、性能和稳定性：
降级 JDK 可能会带来性能改良和 bug 修复，但也可能引入新的性能问题或稳定性问题。在降级之后，通过全面的性能和稳定性测试，确保你的应用程序在新的 JDK 版。
3.3.7、移除的性能：
如果代码应用了 JDK 8 中被移除或弃用的性能。查找 JDK 17 的公布阐明，找到代替的性能或办法，并进行相应的批改。比方 sun.misc.Unsafe 其大部分办法已被标记为 @Deprecated
3.3.8、字节码和运行时差别：
在降级到 JDK 17 后，你的应用程序呈现了意料之外的行为。应用调试工具和日志记录，对代码进行具体考察，查找与字节码和运行时差别相干的问题，并进行相应的修复。例如，JDK 17 引入了 instanceof 指令的新变体 instanceof<type>，用于改良 instanceof 运算符的性能。如果你的代码在 JDK 8 中应用了自定义的字节码操作，须要查看是否须要相应地调整代码。
3.3.9、依赖项更新：
降级到 Spring Boot 3.x 可能须要更新你的应用程序的依赖项，如 Spring Framework、Hibernate 等。解决办法：查看 Spring Boot 的文档和依赖项治理，理解每个版本所需的依赖项版本，并更新你的我的项目配置文件 Maven 以应用相应的版本。确保所有依赖项与 Spring Boot 3.x 兼容。
3.3.10、配置文件变更：
Spring Boot 3.x 可能引入了新的配置属性或更改了现有属性的名称或行为。解决办法：仔细检查你的应用程序的配置文件，特地是 application.properties 或 application.yml，依据 Spring Boot 的文档和迁徙指南，更新和调整属性的名称和用法。
3.3.11、主动配置变动：
Spring Boot 3.x 可能批改了某些主动配置类或默认行为，可能会影响你的应用程序的行为。查看 Spring Boot 的降级文档和公布阐明，理解哪些主动配置类产生了变动，并在必要时进行相应的批改和调整。
3.3.12、测试更新：
Spring Boot 3.x 可能引入了新的测试框架或更改了现有的测试注解和行为。查看 Spring Boot 的测试文档，理解测试框架的更新和变动，并相应地批改和调整你的测试代码
3.3.13、Spring Boot Starter 的命名变动：
在 Spring Boot 2.x 版本中，许多 Spring Boot Starter 的命名形式产生了变动。例如，原来的 spring-boot-starter-web 变为 spring-boot-starter-webflux，spring-boot-starter-data-jpa 变为 spring-boot-starter-data-jdbc 等。Spring Boot 2.x 中，默认的缓存主动配置应用 JCache（JSR-107）作为缓存提供者在 Spring Boot 3.x 中，缓存主动配置产生了变动。Spring Boot 3.x 引入了对 Caffeine 缓存提供者的默认反对
3.4、初探 graalvm
3.4.1、GraalVM 社区版（Community Edition）：
在社区版和企业版本中，如果不指定 GC , 默认都应用的是 Serial GC，而在企业版中能够指定应用 G1 垃圾回收器。G1 垃圾回收器是一种现代化的低提早垃圾回收器，实用于大部分利用场景。而在在企业版中，引入了名为 GraalVM Native Image 的性能，它应用了不同的垃圾回收器。GraalVM Native Image 是一个 AOT（Ahead of Time）编译器，能够将 Java 程序编译成本地机器码，从而提供更快的启动工夫和更低的内存占用。对于 Native Image，GraalVM 企业版应用了垃圾回收器 Substrate VM，它是专门为 AOT 编译的利用程序设计的。
3.4.2、性能优化：
GraalVM 企业版通常会提供更多的性能优化性能和选项。这包含对即时编译（Just-in-Time Compilation）的改良、代码优化和程序剖析等方面的加强。企业版的指标是提供更高效、更高性能的运行环境。
3.4.3、工具和扩大：
企业版可能提供一些额定的工具、库和扩大，以满足企业级应用程序的需要。这些工具可能包含性能分析器、调试器、内存剖析工具和性能监控等。
3.4.4、平安加强：
GraalVM 企业版通常会提供一些平安加强性能，以提供更好的应用程序安全性和爱护。这可能包含对代码审计、破绽扫描和平安加固方面的反对。
3.4.5、跨语言集成：
企业版可能提供更好的跨语言集成反对。GraalVM 企业版具备更宽泛的语言反对，包含 Java、JavaScript、Python、Ruby 等，使得在混合语言环境中开发和运行应用程序更加便捷。
3.4.6、商业反对和服务：
企业版提供商业反对和服务，包含谬误修复、安全更新和技术支持。这能够确保您在应用 GraalVM 时取得及时的反对和帮忙。
4、价值：
4.1、直观价值：
4.1.1、性能晋升：
新版本的 JDK 和 Spring Boot 通常会引入性能改良和优化，包含内存治理、垃圾回收、线程解决等方面的优化。这可能会缩小应用程序的内存占用和 CPU 负载，从而进步零碎的响应速度和吞吐量。再集成 native-image 编译生成的原生镜像的启动速度往往比 JVM 的启动速度快得多，这对于有很多短暂工作的利用场景（例如 serverless 或者函数计算）十分无利
4.1.2、内存治理和垃圾回收晋升：
JDK 的每个版本都在内存治理和垃圾回收方面进行了改良。新的版本通常会引入更高效的垃圾回收算法和内存管理策略，使应用程序可能更无效地利用内存资源，并缩小垃圾回收的进展工夫。这将有助于升高内存占用和缩小 GC 相干的 CPU 开销，而采纳原生镜像后，通常具备比基于 JVM 的利用更低的内存占用，这有利于升高运行时的资源耗费。
4.1.3、资源优化比晋升：
新版本的 Spring Boot 可能会引入更好的资源管理和优化机制。这包含对数据库连贯、线程池、缓存等资源的更无效的治理和利用，以缩小不必要的资源耗费，进步零碎的资源利用率，而应用 native-image 编译后的本地机器代码 更加显著减小应用程序的内存占用。因为 native-image 只蕴含应用程序所需的运行时组件和库，而不须要整个 JVM 的额定开销 镜像大小能缩小 80%，且编译后的本地机器代码不再依赖于 JVM, 缩小应用程序对系统资源的耗费，使得应用程序能够在资源受限的环境中更高效地运行。
4.1.4、并发晋升：
新版本的 JDK 和 Spring Boot 可能会提供更高效的并发解决机制和多线程编程模型。这将使应用程序可能更好地利用多核 CPU，并进步并发性能。通过更好的线程池治理、异步编程模型等，能够缩小不必要的线程开销，进步零碎的并发能力。
4.1.5、节省成本：
通过优化资源耗费，尤其是内存和 CPU，能够升高硬件需要和老本。较低的内存占用和 CPU 负载意味着能够在雷同的硬件配置下运行更多的利用实例，从而节俭硬件老本。此外，较低的资源耗费还能够缩小运维老本和能源消耗。
4.2、久远价值：
4.2.1、长期反对和保护：
JDK 17 是一个长期反对版本（LTS），它将取得长期的官网反对和保护，包含安全更新、谬误修复和性能优化。这意味着咱们的应用程序能够在将来几年内继续受到反对，放弃平安、稳固和牢靠。
4.2.2、技术演进和倒退：
通过降级到最新的 JDK 和 Spring Boot 版本，能够跟上技术的演进和倒退。利用新的语言个性、框架改良和工具，进步开发效率和代码品质。同时，降级也为咱们团队提供了学习和倒退的机会，使他们可能跟上行业的最新趋势和技术标准，进步他们的技术能力和常识广度。
4.2.3、生态系统反对：
随着工夫的推移，与 JDK 和 Spring Boot 相干的生态系统将继续倒退和壮大。降级到最新版本能够使您可能取得更宽泛、更成熟的生态系统反对。这包含更多的第三方库、工具、插件和社区资源，能够减速开发过程、解决问题和提供更丰盛的功能集。
4.2.4、进步开发效率：
新版本通常会引入更多的开发工具和改良，旨在进步开发效率和开发人员的体验。例如，新的语言个性、API 改良、自动化工具和开发工作流程的优化等，都有助于简化开发工作、缩小样板代码，并进步团队的整体生产力。
4.2.5、公司团队能源和职业倒退：
通过降级到最新版本，公司成员能够参加到技术升级的过程中，提出倡议、奉献教训和共享常识。这有助于加强对公司的积极性和归属感，激发他们的职业倒退能源，同时也为他们提供学习和成长的机会。
4.2.6、进步公司在互联网的竞争力：
降级到最新的技术版本能够使部门甚至公司放弃在技术的前沿，并具备更强的竞争力。公司将可能应答新的技术挑战和我的项目需要，提供更高质量、更高性能的解决方案，从而在市场上放弃竞争劣势。
4.2.7、面向未来的筹备：
降级到较新的版本能够帮忙您为将来做好筹备。您的应用程序能够充分利用新的技术和性能，以满足一直变动的业务需要和用户冀望。同时，较新的版本通常会更好地适应新的硬件和部署环境，为您的应用程序提供更好的性能、可扩展性和可靠性。
总结：
总之，降级 JDK 和 Spring Boot 版本，以及应用 native-image 打进去的原生镜像能够帮忙 Java 利用更好地适应云原生环境，进步利用的性能和可扩展性。这些措施能够帮忙 Java 在云原生环境中更好地倒退
作者：京东科技 徐拥
起源：京东云开发者社区