版本信息

环境基本信息

JAVA组件依赖基础信息

存储引擎基础信息

Java版本选型

Java8的思考

当前技术部门在搭建技术架构时对于JDK的选型面临一个问题，凭借以往经历、经验沿用JDK8？使用JDK17？表面看是对JDK版本的选择，但其实是一个涉及技术架构根基的问题。在大部分公司的架构设计中对于新老版本的采用也会有不同的声音：

• 想尝试新技术，紧跟技术浪潮

• JDK8 已问世9年，版本太老了（廉颇老矣尚能饭否，JDK21 已发布）

• JDK8↓ 的垃圾回收很头疼，有没有无需配置或简单配置的一款垃圾回收器，听说ZGC 不错

• 公司要使用SpringBoot3.X、spring6.0 对JDK有版本要求

• 稳~稳~，坑让别人先趟

• 新版任你发，我用Java 8

对于以上声音大概可以归结为：

1. 技术生态持续更新，保证架构的高效、稳定、安全

2. 不得不升

3. 能不升则不升

  对于我们而言升还是不升？

从使用JDK8的角度分析...

• 开发效率：在JDK版本的不断迭代中会对语言本身（表达方式：JDK8 Lambda表达式、Stream API、函数式接口；JDK17 switch、instance、文本块、密封类等）、类库等进行持续的优化以提升开发效率及代码的可读性。固守JDK8版本不享受后续福利？

• 系统稳定性：JDK8 当前官方已经停止更新，随着技术周边生态的升级，如何保证生产环境在后续长时间的迭代过程中的性能、稳定、安全？

• 性能：

  • JDK8 CMS 在大数据场景下略显捉襟见肘，虽然推出了G1，但在处理日益增长的数据量、业务量下难以长久，垃圾回收仍需不断地优化以缩短垃圾回收时间提升吞吐量。

  • 并发能力，在已经发布的JDK21中已经 引入了一种新型的并发编程模式 - “协程” ，协程的引入让并发编程更简单、系统并发能力更优越

• 技术生态发展：

  • Spring：目前spring 已推出了 Springboot3.X、spring6.0 但要求JDK版本最低17

  • Alibaba：

  •   除了Spring， Alibaba 系相关组件（nacos、sentinel、dubbo(官方已推荐 JDK17)、seata等）也已拥抱 Springboot3.0

  • 

  • Apache

    • Apache Flink 1.18.0 已支持 JDK17

    • Apache Hadoop、Spark 已支持 JDK17

    • Apache Tomcat Server 10.0.x 已开始对JDK17的支持

    • Apache 基础工具mave、common 等已支持JDK17

  • JDK主流供应商已支持JDK17

    • Oracle

    • Amazon （OpenJDK）

  •   固守JDK8如何融入持续更新的周边生态？

• 后续升级阻碍：若基于 JDK8 则只能使用开源框架、中间件的部分版本（低版本）。将来如果涉及对部分开源框架、中间件的升级就会有一定的限制性，若整体升级则“牵一发而动全身”，影响稳定性。

不做固步自封(疯)~

  考虑到后续技术团队架构、生态的不断升级、演进，建议 使用高于 JDK8 版本 ，为后续架构的演进预留扩展能力，避免中途大规模升级动作

版本选择

官网：https://www.oracle.com/java/technologies/java-se-support-roadmap.html

通过 JDK 当前发展路径我们可以看到：

• LTS版本：8、11、17、21、25

• EOL版本：9~10、12~16、18、19、22、23、24

LTS - Long Term Support

EOL - End Of Life

对于 EOL 版本官方已不再提供支持维护，因此 EOL 相关版本不在本次选型范围。

JDK8：

JDK8 GA 版本发布于2014年，已有9年的时间，当前官方已经停止维护。虽然JDK8为目前绝大多数以稳定性为主的系统第一选择，但是升级到高版本JDK也只是时间问题。

而且考虑到后续技术架构生态（SpringBoot3、spring6等）的不断升级、发展、稳定等，JDK8 也排除了本次的入围版本范围。

因此 LTS 版本可选性缩小为： 11、17、21、25（GA未发布），但基于 “不冒进、保稳定 促发展 强根基” 原则，将近期发布的版本 21、25 （GA未发布）排除在外。

最终入围 JDK 版本为：11、17

JDK11 VS JDK17

1. 开源性：

JDK 17 binaries are free to use in production and free to redistribute, at no cost, under the Oracle No-Fee Terms and Conditions (NFTC)

    JDK17 根据NFTC协议将免费用于生产和商业用途

2. 安全性、维护性：

   1. JDK11 发布于2018.9，核心支持截止 2023.9月；补丁、安全性支持2032年1月

   2. JDK17 发布于2021.9，核心支持截止 2026年9月；补丁、安全性支持2029年9月

3. 市场占有率及发展趋势：

   1. 数据来自（截止 2023-05-04 ）：https://cloud.tencent.com/developer/article/2278731

4. 新特性支撑：

   1. 组件优化对个人认为重点更新进行介绍，详细：https://www.oracle.com/java/technologies/javase/17-relnote-issues.html#NewFeature

5. 性能：

   1. 垃圾回收性能：参考 OptaPlanner 对JDK11、JDK17 的性能评测结果，可以看出 JDK17 在G1、ParallelGC 性能上相比JDK11要更有优势。

6. 生态结合：

   1. SpringBoot3、spring6 官方要求JDK最低版本为17，不向下兼容

JDK17

经过 基于稳定性、支撑能力、版本特性、生态融合等多方面分析，目前技术架构采用 JDK17 版本

生态支撑

基于目前了解到主流框架 Spring6、SpringBoot3.X、SpringCloud2022.0.x、Spring Cloud alibaba 、Apache tomact、flink 等相关组件、类库已支持JDK17

1. SpringCloud VS SpringBoot version；

2. SpringCloudAlibaba VS SpringBoot version；

SpringBoot版本选型

版本范围

基于上方JDK的选型，对 SpringBoot 的基线版本基本可定为 SpringBoot3.X，SpringBoot3.X目前正式发布的有两个版本 3.0.X 、3.1.X

3.1.X VS v3.0.X

  在对比 SpringBoot 3.1.0 VS v3.0.12 （3.0.x last）的发布特性里并无重大的升级，主要是对工具类库的升级 及 Bug的修复

 V3.1.2

  3.1.X 和 3.0.X 两个版本间主要对类库的升级、BUG 的修复。3.1.0版升级内容：

1. HttpClient ：SpringBoot 3.0 包含了 HttpClient 4 和 5 的依赖管理；但在SpringBoot 3.1 直接使用HttpClient 5，移除了 HttpClient 4 （HttpClient 4 可能会导致使用 RestTemplate 时出现难以诊断的错误）

2. @MockBean 注解：SpringBoot 3.1 升级到 Mockito 5，支持在 JUnit 5 中使用 @MockBean 注解；

3. Hibernate 6.2

   1. SpringBoot 3.1 升级到 Hibernate 6.2

   2. Jackson 2.15，SpringBoot 3.1 升级到 Jackson 2.15

......

    后续版本会对之前版本进行升级和修复，稳定性会有一定提升提升，固从 3.1.0 ~ 3.1.3 版本中选择，但因小版本之间变化不大，目前 选择 3.1.2 做为基线版本。

生态支撑

• SpringCloud VS SpringBoot version

• SpringCloudAlibaba VS SpringBoot version

Nacos版本选型

版本范围

  基于 Dubbo3.X 的选择，Nacos 版本需要 2.0.0 以上

版本对比

  从2021年3月 2.0.0正式版发布至今，2.X版本已经走了接近2年时间，目前已正式对外发布的 last 版本为 2.2.3 。

  在 2.2.3 (May 25th, 2023) 的发布记录中我们发现解决了一些安全风险问题，其中包含 RCE漏洞 （远程代码执行漏洞。修复对部分Jraft请求处理时，使用hessian进行反序列化未限制而造成的RCE漏洞）及 Bug的修复。

  根据官方推荐建议使用此版本，基于 安全、稳定 考虑，对漏洞零容忍的态度，采用 2.2.3 版本 作为基线版本。

  Nacos - RoadMap：

通过Nacos官方公布的后续版本迭代计划可以看出，后续2.X的迭代基本处于优化、维护阶段，版本之间升级变化可能不会太大。3.0 可能会进行大的升级迭代，对于 Nacos 版本选择目前在 2.X 版本中建议使用安全、稳定版本即可。

V2.2.3

  生态支撑

• 支持Dubbo3.X

• Spring

  • 支持spring项目通过jar包的方式引入

• SpringBoot

  • 提供 start，引入start实现自动装配

  • 配置中心： nacos-config-spring-boot-starter

  • 注册中心 ：nacos-discovery-spring-boot-starter

• Spring Cloud Alibaba

  • 提供 start ，引入start实现自动装配

  • 注册中心：spring-cloud-starter-alibaba-nacos-discovery

  • 配置中心：spring-cloud-starter-alibaba-nacos-config

• 云容器：

  • 支持Docker、Kubernetes容器化部署

Dubbo

版本范围

 当前dubbo使用率比较高、稳定的版本主要有两个大版本：Dubbo2.X、Dubbo3.X

Dubbo2.X VS Dubbo3.X

特性比对：

1. 跨语言支撑

   • Dubbo2.X：Java、GolangDubbo3.x

   • 自 Dubbo3 开始，Dubbo 提供了 Java、Golang、Rust、Node.js 等多语言实现

2. 安全性

• 序列化方面

• Dubbo2.X 对发现或收到相关的漏洞报告之后，Dubbo 官方会跟进并升级依赖到最新的安全版本

• Dubbo3.X 在序列化协议安全方面进行了升级加固

3. 协议扩充

• Dubbo3.X在原有Dubbo2.X的基础上增加了 Triple 协议（基于 HTTP2 上构建的 RPC 协议，完全兼容 gRPC），除此外还对众多第三方协议进行了集成，并将它们纳入 Dubbo 的编程与服务治理体系， 包括 gRPC、Thrift、JsonRPC、Hessian2、REST 等。在协议的支撑性更广、协议的传输效率上更高

• Triple 是基于 HTTP/2 的新一代 RPC 通信协议，在网关穿透性、通用性以及 Streaming 通信上具备优势，Triple 完全兼容 gRPC 协议。相较于 Dubbo2.X的HTTP1有更高的性能

• Triple协议优势

4. 服务发现

• Dubbo3.X：Dubbo3 引入了全新的服务发现模型 - 应用级服务发现，以 应用粒度 组织地址数据。数据量小、资源消耗更小、与容器结合更稳定；（Dubbo3在工作原理、数据格式上已完全不能兼容老版本服务发现）

• Dubbo2.X：Dubbo2 接口级服务发现，以 接口粒度 组织地址数据，接口粒度的数据绑定了业务数据，在传输过程中数据量大（较应用级）在大规模集群下可能会存在一些性能问题

Dubbo2.X 接口粒度 VS Dubbo3.X 应用级粒度

应用级粒度服务发现优势 :

• 进一步提升了 Dubbo3 在大规模集群实践中的性能与稳定性。新模型可大幅提高系统资源利用率，降低 Dubbo 地址的单机内存消耗（50%），降低注册中心集群的存储与推送压力（90%）， Dubbo 可支持集群规模步入百万实例层次。

• 打通与其他异构微服务体系的地址互发现障碍。新模型使得 Dubbo3 能实现与异构微服务体系如Spring Cloud、Kubernetes Service、gRPC 等，在地址发现层面的互通， 为连通 Dubbo 与其他微服务体系提供可行方案

5. 路由规则支撑服务网格化

• Dubbo3.X 对 Dubbo2.X 的路由规则进行了重新规划设计 - 服务流量管理，这套统一流量规则将覆盖未来 Dubbo3 的 Service Mesh、SDK 等多种部署形态，实现对整套微服务体系的治理

6. 负载均衡

• Dubbo3 在 Dubbo2 基础上新引入了两种负载均衡算法：

• 基于公平性考虑的单纯 P2C 算法

• 自适应负载均衡，基于自适应方法 adaptive，其试图自适应的衡量 provider 端机器的吞吐能力，然后将流量尽可能分配到吞吐能力高的机器上，以提高系统整体的性能

• 自适应负载均衡 从消费者视角考虑如何将请求分配到当前具有最优处理能力的机器实例，而避免人工指定在某些场景下的不足

7. 云原生

• 服务发现层面，Dubbo3 支持与 Kubernetes Native Service 的融合，并且规划了两种形态的 Service Mesh 方案（基于 Sidecar 的 Service Mesh、无 Sidecar 的 Proxyless Mesh）

7. 性能提升

•  Dubbo3.X 较 Dubbo2.X

• 服务发现资源利用率显著提升。

  • 对比接口级服务发现，单机常驻内存下降 50%，地址变更期 GC 消耗下降一个数量级 (百次 -> 十次)

  • 对比应用级服务发现，单机常驻内存下降 75%，GC 次数趋零

• Dubbo 协议性能持平，Triple 协议在网关、Stream吞吐量方面更具优势。

  • Dubbo协议 （3.0 vs 2.x），3.0 实现较 2.x 总体 qps rt 持平，略有提升

  • Triple协议 vs Dubbo协议，直连调用场景 Triple 性能并无优势，其优势在网关、Stream调用场景

• Memory

V3.2.7

Dubbo3.X 已发布3年左右的时间，新加入的 Triple 协议弥补了Dubbo2.X Http1.X 的性能问题，在整体性能上也较 Dubbo2.X有了很大提升；对于云原生的扩展也在不断的丰富、优化。相信 Dubbo3.X 不久会成为将来的主流趋势。

目前Dubbo3.X已发布到 dubbo-3.2.7 在 releases 的发布记录中可以看到在 dubbo-3.2.0 版中有了比较大的升级，其中包含 支持 JDK17、SpringBoot3，基于 JDK版本选型，我们将从 Dubbo3.2.x 中选择相应的版本。比对 3.2.0 ~ 3.2.7 releases 的发布记录，期间主要是对安全性、BUG进行修复，对支撑类库做了相关的升级，无重大的特性发布。但在 dubbo-3.2.7 版本中已经支持到 JDK21 ，考虑到将来架构演进对JDK版本的扩展性， 采用 3.2.7 作为基线版本。

生态支撑

• 当前 Dubbo3.X 已支持并推荐 JDK17，紧跟技术浪潮，不断迭代

• SpringBoot：基于 SpingBoot3.X 的 dubbo-spring-boot-starter 支撑

• 注册中心：Dubbo3.X 依然可以使用常用的 Nacos、Consul、Zookeeper 等作为注册中心

• 微服务：SpringCloudAlibaba + Dubbo3.x

• 配置中心：Dubbo3.X 依然可以nacos、apollo 作为配置中心

• Sentinel、Skywalking、Zipkin、Pinpoint、Seata、Arthas、Higress 等