[[405391]]

現(xiàn)如今，多少新的概念或產(chǎn)品曇花一現(xiàn)都不足為奇。我們對于一個(gè)未知的事物都會(huì)感到好奇以及充滿期待，就像你突然得知自己要當(dāng)父親了，對孩子的降臨充滿期待一樣，也沒有哪個(gè)父母不希望自己的孩子優(yōu)秀。

或許你并不期待一個(gè)窮人家庭生出來的小孩長什么模樣，智商多少，以及他以后能有多大的成就，這些我們都不會(huì)去關(guān)心。但我想喜歡追星的朋友一定好奇他的偶像的孩子長得像不像他。

這，或許就是主角光環(huán)。

Spring Native就是這樣一個(gè)優(yōu)秀家庭的孩子，在它還未成熟時(shí)，我們意識(shí)已經(jīng)接受了它的優(yōu)秀，不可否認(rèn)，它是被它的父親們懷著遠(yuǎn)大目標(biāo)創(chuàng)造出來的，它的未來是已知的。但它是否能取得像Spring Boot一樣的成績還是未知的。

我最近看了一些關(guān)于它的熱點(diǎn)，一些博主寫的文章，但讓我感覺到的是，寫這些文章的博主或許自己都沒了解Spring Native長什么樣，就是追個(gè)熱點(diǎn)，翻譯一下國外的視頻，或者官方文檔，對比下啟動(dòng)耗時(shí)、編譯耗時(shí)、占用內(nèi)存、編譯后的文件體積等參數(shù)，所以我從他們的文章中了解不到更多。當(dāng)然，我也是來蹭個(gè)熱度的。

很多人都喜歡嘴上夸國產(chǎn)汽車越來越牛了，但行動(dòng)卻很誠實(shí)。有一邊夸比亞迪N.B，一邊掏錢買特斯拉的;有一邊夸華為中華有為，一邊萬把塊錢追趕最新款iphone的。所以優(yōu)秀是一回事，能有什么樣的市場反應(yīng)又是另一回事。

漂亮的姑娘并不一定就搶手，但有趣的靈魂是。

從Spring Native官方文檔來看，我是承認(rèn)它的優(yōu)秀的，我也會(huì)繼續(xù)關(guān)注它，或許將來在合適的項(xiàng)目中去使用它，至少從目前的了解來看，我還不會(huì)只為性能買單，一是對現(xiàn)有項(xiàng)目的改造成本略高，二是出于目前項(xiàng)目的成熟度考慮我們還缺少一些云原生組件的支持。

Spring Native出生自帶光環(huán)，這與當(dāng)初的Spring WebFlux如出一轍，然而幾年過去了，Spring WebFlux有沒有流行起來相信大家也有目共睹。難度是WebFlux不夠優(yōu)秀嗎?當(dāng)然不是。我也曾用WebFlux+R2DBC+Lettuce開發(fā)過一個(gè)消息推送微服務(wù)，也用它開發(fā)過網(wǎng)關(guān)，但我不會(huì)使用它來開發(fā)業(yè)務(wù)項(xiàng)目，它的優(yōu)點(diǎn)不足以讓我們忽略它的缺點(diǎn)，所以它在業(yè)務(wù)開發(fā)上注定不會(huì)流行起來，現(xiàn)在不會(huì)，以后也不會(huì)。至于它的優(yōu)點(diǎn)，別的框架、編程語言難道就沒有嗎?

圖片 https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/

Spring Native provides support for compiling Spring applications to native executables using the GraalVM native-image compiler.

Spring Native 支持使用GraalVM 本機(jī)映像編譯器將 Spring 應(yīng)用程序編譯為本機(jī)可執(zhí)行文件。

Spring Native使用GraalVM的Native Image編譯器在編譯期就將JVM字節(jié)碼編譯成可執(zhí)行鏡像文件(機(jī)器碼)，運(yùn)行在Hotspot虛擬機(jī)之外的GraalVM(編譯時(shí)寫入)，這說明它為了性能將會(huì)拋棄一些運(yùn)行時(shí)特性，如類的延遲加載(常見如遠(yuǎn)程類加載、tomcat動(dòng)態(tài)部署war)、反射、動(dòng)態(tài)代理、Java Agent。

關(guān)于GraalVM：《一文了解GraalVM》https://www.sohu.com/a/375404869_355142

雖然Spring Native可以通過編譯期處理方式支持AOP，將動(dòng)態(tài)代理轉(zhuǎn)為靜態(tài)代理，但并非所有動(dòng)態(tài)代理都能轉(zhuǎn)為靜態(tài)代理。我記得Dubbo框架中的自適應(yīng)SPI機(jī)制就需要根據(jù)請求參數(shù)來生成目標(biāo)代理方法體，這用到了動(dòng)態(tài)字節(jié)碼技術(shù)。同樣的，CGLIB也將不支持，這意味著使用CGLIB實(shí)現(xiàn)的Bean屬性拷貝不能使用，非實(shí)現(xiàn)接口的@Async、@Scheduled也將要改成使用接口，反射也需要靜態(tài)配置。

其次，在微服務(wù)中，我們目前使用的一些調(diào)用鏈追蹤平臺(tái)需要借助JavaAgent實(shí)現(xiàn)無代碼侵入，動(dòng)態(tài)修改類的字節(jié)碼插入埋點(diǎn)代碼后重新加載類的字節(jié)碼。如果使用Spring Native，這些JavaAgent將會(huì)被遺棄，這些調(diào)用鏈追蹤平臺(tái)要么選擇支持在編譯期完成插樁要么就放棄無代碼侵入。

當(dāng)然，Spring Native的目標(biāo)是云原生市場，而在云原生占有一席之地的golang也并不支持這類特性，但并阻止不了開發(fā)者、組織們擁抱它。而Istio這類目標(biāo)讓流量控制、重試、監(jiān)控、鏈接追蹤、負(fù)載均衡、動(dòng)態(tài)路由下沉到基礎(chǔ)設(shè)施層的服務(wù)網(wǎng)格技術(shù)將替代JavaAgent。但…也只是支持進(jìn)程間的鏈路，進(jìn)程內(nèi)方法的鏈路就不關(guān)心了，但…有必要關(guān)心嗎?過多的埋點(diǎn)只會(huì)影響性能。

隨著Service Mesh(服務(wù)網(wǎng)關(guān))、FaaS(函數(shù)計(jì)算，無服務(wù)器)技術(shù)的發(fā)展，相信Spring Navite將會(huì)被很多組織使用，支持GraalVM Native Image的Spring有著快速啟動(dòng)的特性，更好的支持FaaS，同樣體積小構(gòu)建小的容器鏡像也更好的適應(yīng)云原生，減少運(yùn)行時(shí)內(nèi)存占用也將為組織減少更多為此付出的成本。

因此，雖然Spring Native在我看來，與Spring WebFlux也很相似，但至少不會(huì)是難兄難弟，雖然它們的目標(biāo)都是提升性能，但WebFlux強(qiáng)行開發(fā)者改變現(xiàn)有的編程方式，并有很強(qiáng)的API侵入，注定不會(huì)被廣泛接受。而Spring Native只是為保持Spring的特性去支持原生鏡像，開發(fā)者不需要付出很多的學(xué)習(xí)成本就能接受它。

或許這是一個(gè)更直觀的比喻，WebFlux更像是Window Phone系統(tǒng)，需要更多開發(fā)者與組織的支持來構(gòu)建生態(tài)，而Spring Navite更像是鴻蒙系統(tǒng)，采用適配Android應(yīng)用去繼承現(xiàn)有的Android生態(tài)，如果不改變主題，你把手機(jī)交給身邊的朋友，他們不一定看得出這是鴻蒙操作系統(tǒng)。

但即便如此，也有很多未知的因素。

目前也并不只有Spring Native支持GraalVM，與之在同一賽道的還有Quarkus，而且更輕量，然而廣大開發(fā)者也并沒有為此買單，因?yàn)樗谖覀兊氖孢m圈之外，所以Quarkus的流行度并不足以衡量Spring Native的流行度，就像文章前面說的，Spring Native還自帶光環(huán)。

最后一個(gè)不是那么確定的因素，為了性能，你會(huì)選擇Spring Native還是選擇換一門語言如golang呢?我猜選擇Spring Native的至少占九層以上，包括我。雖然golang很簡潔，但不像java一樣能帶給我很多驚喜，創(chuàng)造很多“藝術(shù)”、藝術(shù)。

本文轉(zhuǎn)載自微信公眾號(hào)「Java藝術(shù)」，作者wujiuye。轉(zhuǎn)載本文請聯(lián)系Java藝術(shù)公眾號(hào)。