Spring Cloud项目是否已经不再活跃?

你都已经看到github上的提交活动了，这个活越不活跃，自己就可以做个判断了

用还是会有人在用，毕竟有不少legacy system在用这个东西

但是呢，活跃度应该是不如一些新生的工具了

现在java整个生态，都已经诞生一批新生的工具，国外spring的市场已经发生了动摇

当然你非要问，有没有人用，二极管思维，那我只能告诉你，还有人在用

maven的搜索引擎上，index了三千多万个jars^[1]

那些jars都有人用，至少作者自己在用

哪怕是struts，估计也还是有项目在用

这个就像我们讨论深圳人少了之后，总有人出来说，深圳不是没有人

废话，两千多万人口的大城市，一夜之间变没人，那还世界末日了都

人少的意思是：从两千万减少到一千七百万，这个叫做人少了，不是从两千万减少到一个人都没有

这么如果无法达成共识，那我看这个交流也没有必要继续下去了

把一个加减问题，变成一个有无问题，那这个人不是别有用心就是脑子可能有点那个了

同样道理，要问这个项目有没有人用，肯定有啊

但是可能没有其他的一些项目用的人多

从目前观察到的情况看，java这些年，各个厂都在忙活自己的框架，不完全依赖spring

比如oracle自己有一个helidon框架，red hat有一个quarkus框架，graal项目组自己有一个micronaut框架，加上spring，这四个应该是最近这些年，java的seminar上，比如java one，比如devoxx，这些seminar上，出现频率比较高的几个

老外甚至给这些项目做了个排列，直接贴过来：

这些新兴的项目有一个特点，就是后面写的graalvm大字

其实老外这几年，已经不怎么在微服务上做过多的讨论，而是把重心放到native image这种新出现的编译模式上去

微服务可能外包会关注得多一点，对于搞技术的老外来说，可能还是native image这种带来的诱惑力比较大

截止至spring 6和spring boot 3为止，上述四个框架，都完成了native image的实现

至少官方都支持native image编译，当然编译过程可能会比较折腾，这也不奇怪

本来通往一个目标的道路就是曲折的

随着graal官宣，要把jit和aot并入openjdk

过去两年以及将来几年，可能大多数java工具的目标标的，都在native image上，以及一些模块化处理上（project leyden）

因为这可以剪裁java的运行时和最终编译产物

可以让你用java写的代码，更加精简，启动更快，内存占用更少，这些目标上

围绕着这些目标，各个工具会有比较活跃的动态，比如要实现模块化，es等工具就出现了大量的提交

spring boot为了整个native image，也花了不少力气

像netty，netty 5还没有明确的模块化支持的目标，所以helidon那边搞出了一个nima来替换netty

那nima又是一个很活跃的项目

所以围绕着native image（aot）和project leyden（jlink）/模块化这些目标，会有很多的活动

而且这些应该是将来很长一段时间，各个框架忙活的重点

目前看，像json处理库，log系统等，都已经完成了模块化和native image的支持，那现在就剩下netty以及服务器框架部分了，这一块也最大就是了

今年差不多完成的，应该是es，solr和lucene这几个，这几个都完成了模块化

现在就剩下spring，netty，micronaut和quarkus这几个了，这里值得点名表扬helidon

helidon是目前这几个里面，唯一一个，不仅完成了native image的支持，同时也完成了模块化的框架

其他几个，暂时只是完成了native image，还没完成模块化

但这也是最后，最大的一块了，其他的json，log，search啊这些，基本上模块化都做好了

关注这些目标，你会感受到，来自不同工具的高活跃度

至于微服务，那个，其实也就那样了吧，硬要说有什么可搞了，好像也没有了，感觉跟几年前区别并不大

评论区不可避免又讨论起spring和di了

给你们提供点素材，现在各个jvm的gc都相对成熟了，所以你全部new，其实问题并不大

不需要你cache，gc随便选个zgc或者shenandoah，都可以很好滴address这些new出来对象的gc问题

现在对象慢慢变得跟原始数据类型一样，随便用，用完丢弃

然后除了new以外，还可以用static import

java缺省的虚拟机hotspot会对方法区做gc处理，所以你也不用担心定义了太多的static方法，导致方法区溢出，内存泄漏

其实还有第三个，interface的default方法，也可以用来实现类似spring里面普通bean的效果

你让你的controller直接继承对应default方法的interface就好了

这样你也不用static import了，也不用new了，直接implements就可以用了

当然要注意default方法自身不要命名冲突了

所以方法其实很多，非常多，单纯的di，并非必需

反正在一些非spring的轻量级场合下，你大可以用这几种手段，来整理规范你的代码

一个典型场景就是在写javafx的时候，我一般会建议用户，不需要引入过多的比如spring的jars，直接用上述三种方法之一，实现类似的效果

实际开发下来，效果并不差，代码也能很好滴组织起来

而且因为没有引入spring那么多依赖，所以做模块化精简运行时以及native image，都变得容易起来

这些都是手段和工具，用户完全可以根据自身需要和需求，来决定用什么工具