如今，有多少新概念或产品转瞬即逝并不奇怪。我们都对一件未知的事情充满好奇和期待，就像你突然知道自己要当爸爸了，对孩子的到来充满期待一样。没有父母不希望自己的孩子出类拔萃。可能你不指望一个穷人家出身的孩子长什么样，智商是多少，未来能取得多大的成就，这些我们都不关心。不过我想喜欢追星的朋友们一定很好奇他家偶像的孩子是不是长得像他。这，或许，就是主角的光环吧。SpringNative就是这样一个优秀家庭的孩子。在它不成熟的时候，我们的意识已经接受了它的优秀。不可否认，它是先辈们怀着崇高的目标创造的，它的未来可知。的。但能否达到和SpringBoot一样的效果，还是个未知数。最近看了一些关于它的热点，一些博主写的文章，但是感觉写这些文章的博主可能不知道SpringNative长啥样，随便追一个热点，翻译国外的视频，或者官方文档，比较启动时间，编译时间，内存占用，编译后的文件大小等参数，所以从他们的文章中无法学到更多。当然，我也是来蹭热度的。很多人喜欢吹嘘国产车越来越好，但他们的行为却很老实。有的一边夸BYDN.B一边花钱买特斯拉；一些人一边称赞华为在中国的承诺，一边用几万追逐最新款的iPhone。所以优秀是一回事，能有什么样的市场反响又是另一回事。漂亮的女孩不一定受追捧，但有趣的灵魂才是。从SpringNative官方文档来看，我承认它很优秀，我会持续关注它，说不定以后会用在合适的项目中。至少从目前的理解来看，我不会只为绩效付费，一是现有项目的改造成本略高，二是由于目前项目的成熟度，我们还缺少一些云原生组件的支持。SpringNative天生自带光环，与当初的SpringWebFlux一模一样。不过几年过去了，SpringWebFlux是否流行起来，大家是有目共睹的。难点是WebFlux不够好吗？当然不是。我也用WebFlux+R2DBC+Lettuce开发过一个消息推送微服务，也用过它开发过一个网关，但是我不会用它来开发业务项目。它的优点不足以让我们忽视它的缺点，所以它在业务发展中注定不会流行起来，现在不会，以后也不会。至于它的优点，难道没有其他框架和编程语言吗？图片https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/SpringNative支持使用GraalVM本机映像编译器将Spring应用程序编译为本机可执行文件。SpringNative支持使用GraalVM本机图像编译器将Spring应用程序编译成本机可执行文件。SpringNative在编译时使用GraalVM的NativeImage编译器将JVM字节码编译成可执行的镜像文件（机器码），在Hotspot虚拟机外运行GraalVM（编译时编写），由此可见它是为了性能而将一些运行时特性丢弃，比如类的懒加载（常见的比如远程类加载，tomcat动态部署war），反射，动态代理，JavaAgent。关于GraalVM：《一文了解GraalVM》https://www.sohu.com/a/375404869_355142SpringNative虽然可以通过编译时处理支持AOP，将动态代理转为静态代理，但并不是所有的动态代理都可以转为静态代理。记得Dubbo框架中的自适应SPI机制需要根据请求参数生成目标代理方法体，使用的是动态字节码技术。同样的，CGLIB也不会支持，也就是说不能使用CGLIB实现的Bean属性copy，没有实现接口的@Async和@Scheduled也会改成使用接口，反射也需要静态配置。其次，在微服务中，我们目前使用的一些调用链跟踪平台需要使用JavaAgent实现无代码入侵，动态修改类的字节码，插入嵌入代码，然后重新加载类的字节码。如果使用SpringNative，这些JavaAgents将被抛弃，这些调用链跟踪平台要么选择支持编译期插桩完成，要么放弃无代码入侵。当然，SpringNative的目标是云原生市场，而在云原生有一席之地的golang不支持这样的特性，但不妨碍开发者和组织拥抱它。而Istio等旨在让流量控制、重试、监控、链路跟踪、负载均衡、动态路由下沉到基础设施层的服务网格技术，将取代JavaAgent。但是……只支持进程间的链接，进程内方法的链接不关心，但是……有必要关心吗？埋点太多只会影响性能。随着ServiceMesh（服务网关）和FaaS（函数计算，无服务器）技术的发展，相信SpringNavite会被很多组织使用。支持GraalVMNativeImage的Spring，具有快速启动的特点，更好的支持FaaS。构建体积小的小型容器镜像也更适合云原生，减少运行时内存使用也将为组织降低成本。因此，虽然SpringNative在我看来和SpringWebFlux有些相似，但至少不会是难兄难弟。尽管他们的目标是提高性能，但WebFlux迫使开发人员改变现有的编程方式，并且具有很强的API入侵性，注定不会被广泛接受。但SpringNative只支持原生镜像，保持Spring的特性，开发者无需付出大量学习成本即可接受。或许这是一个更直观的比喻。WebFlux更像是一个WindowPhone系统，需要更多开发者和组织的支持来构建生态，而SpringNavite更像是一个鸿蒙系统，适配Android应用继承现有的Android系统。生态，如果不换主题，把手机递给朋友，他们不一定看出来是鸿蒙OS。但即便如此，也有很多未知因素。目前支持GraalVM的不仅仅是SpringNative。Quarkus也在同一轨道上，而且更轻。然而，大多数开发者并没有为它买单，因为它在我们的舒适区之外，所以Quarkus的流行度不足以衡量SpringNative的流行程度。文章前面提到，SpringNative也有自己的光环。最后一个因素不太确定。为了性能，你会选择SpringNative还是选择其他语言比如golang？我估计SpringNative的选择至少有九层，包括我在内。golang虽然很简洁，但是并没有像java一样给我带来很多惊喜，创造了很多“艺术”和艺术。本文转载自微信公众号《爪哇艺术》，作者无九爷。转载本文请联系爪哇艺术公众号。
