这篇文章之所以说Eureka，是因为它还是有一定的话题性的。也就是说，在SpringCloud的加持下，Eureka作为注册中心的市场占有率是相当高的，最有可能成为第一（非官方数据，笔者个人直觉）。对或错？这，虽然有点不可思议，但是一图抵千言：结语：真的，毋庸置疑！！！谁在提交代码？继续看图：一直提交代码的作者居然是SpringCloud的作者，不是Netflix的工程师？事实上，SpencerGibb确实有很多commit，但绝不是他一个人。但他的力量源泉却十分充足。作为SpringCloud项目的负责人之一，他还要负责集成ReleaseTrain上的组件。归根结底，谁最疼，谁就推！PS：代码肯定不会是他一个人写的（commit也有很多Netflix的工程师），但是主要推动者之一肯定是他为什么还在维护Eureka？既然Netflix官方不愿意继续开发Eureka，为什么还要迭代升级呢？其中一个很重要的原因是：Eureka作为配置中心组件已经足够优秀了！！！整体设计、性能、性能、代码水平……都非常好。没有明显的缺点：性能可能是一个，但只要不是超大规模集群，都不是问题。下面放一张各个注册中心的对比图感受一下“艰难”：乍一看，Nacos似乎是赢家？但是，“国产软件”想要走向世界，还有很长的路要走。这不是体现在它实现的功能上，而是体现在它实现的非功能上（比如文档、宣传、设计、代码层面等）。此更新的目的是什么？结合SpringFramework、SpringBoot、SpirngCloud的发布节点，以及上面截图中SpringCloud作者一直在提交代码的迹象，本次更新的目的不言而喻：继续拥抱SpringCloud。这不，最新的SpringCloud2022已经“拥抱”了它：这次升级的目的在ReleaseNote中也有说明：这个版本2.0.0是新作，和2.x-archive分支完全是两个不同的东西从代码分支也可以看出：在本次升级中，EurekaServer的HttpAPI接口和数据结构都没有改变。言外之意：在协议层面，100%向后兼容，兼容1.xClient客户端。所以这次升级的主要目的是：SpringFramework6.0兼容SpringBoot3.0，并拥抱JakartaEE9.what'snew（新特性）既然升级已经成为事实，那也不是佯攻。那就来看看新版本带来了哪些新特性吧。虽然是大版本号的升级，但是功能上不会有太大变化。简单看一下。最低版本需要JDK8（运行测试需要JDK11及以上版本，因为测试依赖基于JakartaEE9的Jetty）说明：原生EurekaClient&Server的代码可以用JDK8正常构建，使用SpringBoot3.0.0和SpringCloud2022.0.0估计不会有人直接用原生的Eureka。一般会结合SpringCloud，这也是“官方推荐”。其他变化众所周知，Eureka是CS模式，分为Client和Server。如前所述：本次升级的协议层面完全没有变化，但这并不代表代码层面没有变化。Java客户端API的2.0.0版不向后兼容1.x。言外之意：虽然接口协议没变，但是实现接口的代码API发生了变化，不兼容1.x。我们知道Eureka使用GlassfishJersey客户端发送Http请求，版本越强是造成这种不兼容的主要原因：Eureka1.x版本默认使用Jersey1.x（可选支持Jersey2.x），而Eureka版本2.0.0使用球衣3.x。从Jar包层面可以看出，除了javax.*->jakarta.*外没有太多变化。官方的描述是2.0.0中的大部分Java客户端API保持不变。另外，eureka-server模块现在不能直接部署为WAR包，因为“官方”（这里主要是指Spring官方）认为没有这个必要，毕竟你一个人裸跑的可能性不大.推荐的使用方式是作为SpringCloudNetflix的一部分在SpringBoot应用程序上运行，非常方便。兼容性例子的大版本号已经升级了，还是有一定的堵塞，但是官方一直强调变化不大，这是怎么回事？为了保险起见，笔者跑了几个典型案例来看看：eureka-server：下图中可以看到1.x和2.x的后台页面有相同的服务注册。笔者启动了一个基于SpringCloud2021版本的应用（基于1.xeureka-client），分别注册到1.x和2.xeureka-server。情况是：完全兼容，没有任何违和感，符合官方协议级别，100%兼容集群模式。1.x和2.x可以无缝组成集群模式，笔者亲测！这里就不发图了，留给大家玩玩。免责声明：本文案例仅作简单现象及效果测试，不对最终生产环境负责。请酌情参考摘要本次大版本号升级，虽然不是虚张声势，但也只是小事一桩。对你之前学习的Eureka知识和源码不构成影响，基本没有变化，这也是好事。
