[[405391]]

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

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

這，或許就是主角光環。

Spring Native就是這樣一個優秀家庭的孩子，在它還未成熟時，我們意識已經接受了它的優秀，不可否認，它是被它的父親們懷著遠大目標創造出來的，它的未來是已知的。但它是否能取得像Spring Boot一樣的成績還是未知的。

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

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

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

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

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

圖片 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 本機映像編譯器將 Spring 應用程序編譯為本機可執行文件。

Spring Native使用GraalVM的Native Image編譯器在編譯期就將JVM字節碼編譯成可執行鏡像文件(機器碼)，運行在Hotspot虛擬機之外的GraalVM(編譯時寫入)，這說明它為了性能將會拋棄一些運行時特性，如類的延遲加載(常見如遠程類加載、tomcat動態部署war)、反射、動態代理、Java Agent。

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

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

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

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

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

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

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

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

目前也并不只有Spring Native支持GraalVM，與之在同一賽道的還有Quarkus，而且更輕量，然而廣大開發者也并沒有為此買單，因為它在我們的舒適圈之外，所以Quarkus的流行度并不足以衡量Spring Native的流行度，就像文章前面說的，Spring Native還自帶光環。

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

本文轉載自微信公眾號「Java藝術」，作者wujiuye。轉載本文請聯系Java藝術公眾號。