Red Hat最近發佈了Quarkus，這是一個爲GraalVM和OpenJDK HotSpot量身定製的Kubernetes原生Java框架。繼InfoQ對其發佈所做的初步報道之後，我們又與Red Hat的幾位專家做了進一步交流，以瞭解該項目的開發動機、應用場景和未來的發展方向。
在雲時代，容器、Kubernetes、微服務、功能即服務（Faas）和雲原生應用正在提供更高水平的生產力和效率，而Quarkus成爲了其中一個非常有趣的選擇。
爲此，InfoQ採訪了Red Hat首席高級產品經理John Clingan和Red Hat工程副總裁Mark Little。
InfoQ：Quarkus旨在使Java成爲Kubernetes和無服務環境中的領先平臺。這個想法是如何產生的？你們爲此研究了多少年？
Red Hat：Red Hat是最早發現在容器中使用JVM存在某些侷限的組織之一，我們已經並且仍在設法解決其中的一些侷限。我們在最近的Red Hat開發者博客文章中討論了這件事。今天，JVM上的Java應用可以在容器中正常運行，我們的客戶也可以在生產環境中使用這種組合。但僅僅改進JVM是很難解決某些侷限的。
其中一個例子是，在JVM上運行企業級Java應用所需的漫長初始啓動時間和龐大內存消耗。我們Red Hat一直在尋找類似於Java的GNU編譯器和Avian項目這樣的解決方案，但是當Java社區中出現了GraalVM後，我們意識到與這個項目合作有很大的潛力。
InfoQ：Red Hat開發Quarkus的靈感源自哪裏？
Red Hat：當我們搞明白GraalVM的工作原理時，我們意識到爲了獲得所有的收益就必須從整體層面考慮問題，不僅要從VM的層面入手，還要考慮框架層面的情況。使用Java爲GraalVM開發原生應用時會有一些限制，主要是圍繞Java的一些更動態的功能，例如反射等；而GraalVM的優勢又需要這些限制爲基礎。對於幾乎沒有依賴關係的應用來說，問題並不是很難解決；但在開發企業級Java應用時問題規模很快就會超出預期了。
開發者們傾向於使用許多不同的框架。其中流行的一個框架是Hibernate，它是最常用的對象關係映射框架，用於輕鬆訪問數據庫內容。若要讓Hibernate在GraalVM上完美工作，需要對Hibernate的原理有很深入的瞭解，還需要深入瞭解JVM和GraalVM的運行機制。在這個實驗中，我們發現了一個創建通用架構的機會，使其它框架可以更容易地接受GraalVM的特質。
我們使用Quarkus中的擴展系統來移植更多的項目，比如我們的Eclipse MicroProfile實現項目（SmallRye）和RESTEasy。該列表現在大約有40個擴展，數量還在增加之中。 Quarkus甚至獲得了swagger-ui帶來的第一次社區擴展。現在，無論企業級Java開發者是在使用Java EE、MicroProfile還是Spring，都會很容易熟悉並上手這個Java棧。
InfoQ：在Quarkus發佈後不久，Thorntail 4.x的開發就宣告結束，Thorntail 2.x的支持將截止到2020年11月。Quarkus對Payara和Tomitribe等其他Java中間件項目會有何影響？
Red Hat：Quarkus帶來了一些非常創新的功能，如擴展API、擴展生態系統，以及統一命令式和反應式編程模型。對其他項目的最大影響在於Eclipse MicroProfile，這裏我們用上了下一代企業級Java規範。MicroProfile的目標是雲原生Java。而Quarkus是一個使用統一的命令式和反應式編程模型實現更先進的雲原生部署方案的示例。
我們可以將自己在Quarkus中的這些想法與其他實現（如Payara和Tomitribe）的經驗結合起來，通過MicroProfile和Jakarta EE推動行業向前發展。需要注意的是，在我們嘗試創建規範之前，必須首先進行創新。將一個想法確定爲規範可能需要幾個月甚至幾年的時間，因此要花的時間肯定會很久。
InfoQ：開發者對Quarkus有哪些期望？
- 爲Kubernetes帶來理想的容器優先體驗
- 毫秒爲單位的快速啓動，從而實現無服務Java的冷啓動，支持響應更快、可擴展的環境
- 最小內存佔用可以達到標準Java流程的十分之一，可以帶來更大的密度，從而提高系統的整體彈性。
- 架構基於12要素應用的理念，幫助開發更健壯和可靠的應用程序。
爲開發者帶來真正的樂趣
有態度，有良好集成的平臺，支持命令式和反應式風格
基於最出色的標準和OSS創建
InfoQ：GraalaVM當前支持的語言（如Scala和Python）可以與Quarkus一起使用嗎？如果是的話，你能舉一些例子嗎？如果不能，它們將來會得到支持嗎？
Red Hat：Java仍然是企業和Red Hat客戶主要使用的語言，因此我們現在還是會把精力集中於此。在Java之外我們也會在實驗中考慮Kotlin，並會注意社區的反饋。
InfoQ：能否多介紹一些Quarkus Metrics的信息？
Red Hat：Quarkus通過Eclipse MicroProfile Metrics規範下的SmallRye Metrics實現來應用的監控。它爲應用暴露了一組默認的基本指標，同時還使開發者能夠添加自定義應用指標。所有指標均可從應用的/metrics端點訪問，並可由Prometheus等監控系統篩選。Quarkus還提供健康檢查支持和分發追蹤功能，使應用更易操作。
InfoQ：Quarkus的發佈週期是怎麼安排的？
Red Hat：Quarkus引起了人們極大的興趣，所以我們希望儘可能積極響應。我們大約每隔幾周就會提供功能和錯誤修復，直到我們認爲反饋已經夠好，也有足夠多的開發者上手使用前都會這樣做。
我們的主要目標之一是幫助社區編寫擴展。Quarkus對我們來說是一個生態系統。
InfoQ：你們是否計劃保持對早期版本的向後兼容性？
Red Hat：向後兼容對我們Red Hat和我們的社區非常重要。但我們是一個年輕的項目，創新速度很快，很難這麼早就對此下結論。但我們將與社區共同來決定“何時、爲何與怎樣做”的內容。
好的一面是Quarkus站在巨人的肩膀上：Hibernate、Vert.x、Camel、Netty、RESTEasy等等，它們都是有着向後兼容歷史的成熟框架。Quarkus簡單地暴露了這些框架的API。我們已經看到很多社區成員以極快的速度將Java EE應用程序移植到Quarkus中。這就是優秀的成熟框架與標準的威力所在。
InfoQ：Quarkus的路線圖是怎樣的？
Red Hat：首先，這個社區成立不久，我們想聽聽人們對Quarkus的用途和需求。
我們認爲生態系統也非常重要；我們希望Java生態系統能夠接受Java的這種新範式轉變，因爲我們認爲它是未來趨勢。因此我們將許多精力投入到爲開發人員使用和喜愛的框架編寫擴展上。
這裏正是困難所在。我們推出Quarkus是要實現一個遠大目標，而要達成這一目標還有很多工作要做。我會列出主要的任務，但請記住，社區及其需求是推動路線圖發展最重要的因素：
- 無服務器：Quarkus的低內存使用率和極快的啓動時間使其成爲FaaS功能框架的理想選擇。
- 命令和響應：在雲原生彈性應用中響應是至關重要的。我們已經通過統一編程模型來展示了我們的目標。現在是時候擴張地盤了。例如，我們正在探索響應式非阻塞方法來提升持久性。
- 安全性：如何應對行業不得不習慣的大量CVE？ 我們從Wildfly的經驗中學到了很多東西，並期待在不久的將來Quarkus能做到很多事情。
- 容器和Kubernetes：應用沒有部署則毫無價值。Quarkus應用程序在容器平臺和Kubernetes上的部署有很多可以改進的空間。
InfoQ：你們在Quarkus中編譯時使用的是什麼啓動技術？
Red Hat：這裏有很多技巧，說一下我們認爲最有趣的方面吧。Quarkus的一個關鍵點是將許多傳統框架在啓動時做的事情轉移到了編譯階段：包括類路徑掃描、反射、解析配置、收集元數據和構建運行時模型等。這樣做有如下好處：
只在編譯時把工作做一次就夠了，不用在每次應用啓動時再來一遍；
以往在JVM中，引導框架所需的所有代碼都會佔用內存（類元數據等），現在則根本不需要。
這樣我們就能使Quarkus應用飛快啓動、高速接受請求，並儘可能壓縮內存開銷。
Quarkus擴展的另一個有趣之處在於，它們可以儘量幫助GraalVM執行冗餘代碼清除算法。 GraalVM在檢測不必要的調用路徑方面做得非常出色，但它需要框架的幫助才能知道可選的依賴項對於特定應用程序是否真的可供選擇。這可能有點無趣，但它的確會帶來回報。
InfoQ：開發者獲得該技術的最佳方式是什麼？ 開發者與社區互動並提出問題最好的途徑有哪些？
獲取Quarkus：請參閱入門指南
Twitter：@QuarkusIO
聊天：Zulip聊天室
查看英文原文：Quarkus Java Framework: Q&A with John Clingan and Mark Little