Grails框架的现状：生命周期终止、Spring Boot依赖与后续策略
目录
在本文的姊妹篇中，我探讨了 Grails 在 Apache 软件基金会（ASF）旗下的复兴：历时 18 个月的迁移、技术现代化，以及作为 ASF 顶级项目发布的 Grails 7。这是一个好消息，也是社区工程领域一项真正令人印象深刻的成就。
本文将探讨同一问题的另一面。
虽然 Grails 在不断前进，但许多基于它构建的应用程序却无法保持同样的步伐。结果就是，框架的发展方向与大量生产系统所处的现状之间出现了越来越大的鸿沟。本文旨在探讨如何理解这一差距，以及有哪些应对方案。
转折点
Grails 与现代 Spring Boot 和 Java 基准的对齐，将我们带到了 2026 年的一个关键转折点。虽然框架正在复兴，但底层生态系统的“重力”正在发生偏移。许多遗留的 Grails 应用程序仍然绑定在即将达到或已经达到生命周期终点（EOL）的 Spring Boot 和 Java 版本上。
Grails 版本现状
Apache Grails 的支持计划清楚地说明了这一点：
- Grails 3 和 4 已停止支持。
- Grails 5 于 2024 年 6 月停止支持。
- Grails 6（最后一个非 ASF 版本，6.2.3 于 2025 年 1 月发布）于 2025 年 6 月停止支持。
- Grails 7 处于活跃维护期，支持至 2026 年 6 月。
- Grails 7.1 和 8 处于活跃开发阶段，Grails 8 的维护支持目标为 2026 年 12 月。
这是 Grails 层面的情况。而在其之下，情况则更为复杂。
Spring Boot 的引力作用
在这之上，Spring Boot 的时间线产生了自身的引力。
Spring Boot 遵循六个月的发布周期，每个版本大约有 13 个月的开源支持期。这听起来很慷慨，但如果列出日期，情况就不同了：Spring Boot 3.3 的 OSS 支持于 2025 年 6 月结束。3.4 于 12 月结束。3.5 支持至 2026 年 6 月。Spring Boot 4.0（于 2025 年 11 月发布）的 OSS 支持至 2026 年 12 月。
对于仍在运行 Spring Boot 2.x 的团队来说，开源支持早在多年前就已结束，目前仅剩商业扩展支持。这扇窗口并没有猛然关闭，而是在稳步缩小。每一个版本被淘汰，都会让下一次升级变得更加困难。
总而言之，这不仅仅是一个单一的截止日期，而是一场缓慢发生的“依赖断崖”。
风险的真实面貌
企业面临的主要风险通常不是这些系统会突然停止工作。成熟的 Grails 应用程序通常非常稳定。真正的风险在于，当组织失去了对依赖项健康状况的可见性，并在未完全意识到的情况下脱离了受支持的状态时，问题会在悄无声息中逐渐积累。
在 Java 生态系统中，供应链的健康状况远比发布当天的兴奋感重要得多。
一个运行在 Spring Boot 2.x 和 Java 11 上的 Grails 4 团队，不会在某天早晨醒来发现应用程序崩溃了。最终他们面对的，是无法修补的 CVE 漏洞，或是合规审计中被标记为不受支持的组件，又或是无法支持所需 Java 版本的新集成需求。
危险不在于突发性故障，而在于无人监控的风险逐渐积累。
务实的中间地带
在实践中，大多数组织并非在“明天就升级”和“什么都不做”之间做选择。现实情况很少如此简单。投资组合约束、监管时间表以及有限的工程能力，意味着许多团队在规划下一步行动时，需要一个受支持的“缓冲地带”。
商业化的 EOL（生命周期终点）持续支持正逐渐成为一种务实的中间地带。越来越多的服务商专门为关键开源组件提供社区停止支持后的维护服务，这为团队提供了喘息空间，避免了被迫进行仓促或规划不当的迁移。
即便是 ASF 本身也承认这一现实：基金会不提供商业支持，但它也意识到并非每个人都能跟上上游的发布节奏。
升级是一种行动，而非策略
面对 EOL 风险，人们的本能反应是“直接升级”。最终，升级确实是正确的做法。但将升级视为一种策略而非行动，则忽略了现实世界系统的复杂性。
一个 Grails 4 应用程序不仅仅是一个 Grails 应用。它还是一个运行在特定 Java 版本、带有特定传递依赖项、并部署在特定基础设施上的 Spring Boot 2.x 应用。
升级 Grails 意味着升级 Spring Boot，这意味着升级 Java，也意味着需要重新验证每个集成点、每个测试套件以及每个部署流水线。
对于只有一个应用的团队来说，这尚可管理。但对于拥有多个服务组合的团队（其中一些服务甚至由已离职人员构建）来说，这是一项跨越多个季度的工程任务。
假装问题不存在并不能缩小问题，只会让计划变得更糟。
该如何应对
了解你正在运行的内容
这听起来很简单，但往往并非如此。Fat JAR、Shaded 依赖、容器、厂商分支、嵌入式运行时：随着时间推移，即使是发布系统的团队也可能不再确定内部到底包含了什么。SBOM（软件物料清单）不仅仅是洞察，更是制度性的记忆。从这里开始。
了解你的风险窗口
将你的 Grails 和 Spring Boot 版本与支持时间表进行对比。明确哪些组件仍在支持期内，哪些即将 EOL，哪些已经过期。这不需要商业工具，只需要有人花一天时间整理电子表格。
必要时买时间
如果短期内无法进行全面升级，那么针对 EOL 组件的商业持续支持可以确保你的系统在规划期间保持在受支持的状态。这不是永久的解决方案（除非你正准备很快淘汰该应用），但对于需要喘息空间的团队来说，这是务实之举。
商业 EOL 支持
如果你目前正在评估旧版 Grails 环境的支持状况，了解 Java 生态系统中可用的持续支持选项是值得的。过去几年，这一领域已经发生了显著变化。
参考此处获取一些“官方”建议。
我本人就职于列表中的一家公司：HeroDevs（免责声明详见后文）。我们为 Grails 以及许多其他 Java 和非 Java 产品提供支持。
提供 EOL 支持并非易事，需要特定的技能和知识，而我相信这正是 HeroDevs 的优势所在。访问网站：https://herodevs.com
将升级规划为“项目”而非“任务”
如果你有多个处于不同版本的 Grails 应用，请对工作进行排序。按风险暴露程度而非便利性来确定优先级。将“依赖断崖”视为必须面对的工程约束，并为其提供相应资金支持。
总结
Grails 在 ASF 下的复兴是真实的，且意义重大。但这并不能追溯性地保护那些构建在早期框架版本上的应用程序。这些系统需要属于它们自己的规划。
在一个只推崇新事物的行业中，维护旧系统安全且受支持的工作很容易被忽视。但这或许本不该被忽视。
资源
Apache Grails 支持时间表 Spring Boot 生命周期终点日期 Grails 7.0.0 发布公告
作者注：完全披露
出于透明度考虑：我供职于 HeroDevs，该公司为生命周期终点的开源组件（包括 Java 生态系统框架）提供扩展安全支持，并通过其可持续性计划资助开源维护者。
文中提及 HeroDevs 工具或服务，是因为我确实认为其所提供的方案具有重要意义。我对开源可持续性和 EOL 风险的观点是独立形成的，且早于该雇佣关系。
文章 Grails Isn’t Done Yet (Part 2): EOL, Spring Boot, and What Comes Next 最早出现在 foojay 上。