[[405391]]

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

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

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

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

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

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

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

從Spring Native官方文檔來看，我是承認(rèn)它的優(yōu)秀的，我也會繼續(xù)關(guān)注它，或許將來在合適的項(xiàng)目中去使用它，至少從目前的了解來看，我還不會只為性能買單，一是對現(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)，但我不會使用它來開發(fā)業(yè)務(wù)項(xiàng)目，它的優(yōu)點(diǎn)不足以讓我們忽略它的缺點(diǎn)，所以它在業(yè)務(wù)開發(fā)上注定不會流行起來，現(xiàn)在不會，以后也不會。至于它的優(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í)寫入)，這說明它為了性能將會拋棄一些運(yùn)行時(shí)特性，如類的延遲加載(常見如遠(yuǎn)程類加載、tomcat動態(tài)部署war)、反射、動態(tài)代理、Java Agent。

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

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

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

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

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

因此，雖然Spring Native在我看來，與Spring WebFlux也很相似，但至少不會是難兄難弟，雖然它們的目標(biāo)都是提升性能，但WebFlux強(qiáng)行開發(fā)者改變現(xiàn)有的編程方式，并有很強(qiáng)的API侵入，注定不會被廣泛接受。而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è)不是那么確定的因素，為了性能，你會選擇Spring Native還是選擇換一門語言如golang呢?我猜選擇Spring Native的至少占九層以上，包括我。雖然golang很簡潔，但不像java一樣能帶給我很多驚喜，創(chuàng)造很多“藝術(shù)”、藝術(shù)。

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