Quarkus vs. SpringBoot - Reddit

banq發表於2022-05-05
Spring Boot

1、Quarkus是很好，但是 Spring Native 出現時，人們空i不願意學習完整的其他堆疊。
GraalVM的一個人昨天在一次會議上： Spring Native 甚至會包含在下一個主要的 Spring Boot 版本中，該版本將在2022年秋季釋出。


2、基本上是說遷移到 Quarkus 可能帶來的好處並沒有超過負面影響。
關於 Quarkus 的一些好處：
  • 學習曲線，這比人們預期的要小得多，我一起工作的一些 Spring 開發人員在一天左右的時間裡感覺 Quarkus 比 Spring 更容易，但我的經驗是這取決於專案。
  • 速度，Quarkus 只是更快（至少根據我參與的測試）並且在相同數量的資源上執行更多的工作，再次根據我參與的測試，應該提到的是，這是沒有移動的為本地人。
  • 開發者速度，我知道這聽起來像個蹩腳的東西，但開發者快樂的想法實際上似乎奏效了，我和我認識的使用 Quarkus 的人似乎更喜歡它，並不是說我不喜歡 Spring Boot，當您考慮了一些框架，甚至 Spring Boot 也很高興使用 :)



3、Quarkus存在不重視kotlin的問題，例如實時重新載入不起作用。
另一種情況下，屬性的建構函式注入會不起作用，因此欄位在執行時為空，儘管沒有被標記為可空。
我經歷過許多類似這樣的奇怪錯誤，但隨著時間的推移，它變得更好了，我絕對更喜歡 Quarkus 而不是 Spring Boot。
很遺憾，kotlin 似乎是二等公民


4、兩者基準測試在效能上有巨大的差異，但無法確定其原因......。
主要原因是Quarkus在構建時做了傳統Java在執行時做的事情。這包括。
  • Classpath掃描
  • 配置解析
  • 初始化元件

Quarkus應用程式只包含執行時需要的類。這種預處理導致了更少的記憶體使用和更快的啟動時間。然而，就像任何事情一樣，也有取捨的問題。其中之一是，如果你是一個reflection發射的重度使用者，Quarkus對你來說並不是很好。

完整的解釋在這裡：https://quarkus.io/container-first/


5、我去年一直在使用quarkus，它的文件似乎很缺乏，功能似乎也有點不足，它只是沒有給人帶來很多信心。也許對於一個簡單的微服務來說，從Rdbms中暴露出粗糙的操作，quarkus是偉大的，但對於更復雜的應用程式來說，它似乎有點業餘了。


6、如果我們處在一個新的環境中，只選擇Quarkus和Spring，我毫不懷疑Quarkus將勝出。我以前用過它，在功能和效能方面都給我留下了深刻的印象。我也沒有遇到任何可靠性問題或其他人報告的重大錯誤。

問題是，在已經有一個巨大的事實標準（Spring）的世界裡，它是一個小眾產品，而作為這樣一個標準，它有一系列巨大的優勢。文件、例子、開發人員的熟悉程度、庫的生態系統等等都是Spring的巨大優勢--而Quarkus則不然。我有時不得不深入到原始碼中去尋找Quarkus問題的答案，僅僅是因為沒有文件。

我並不反對使用新的框架--遠非如此，我總是很好奇，願意嘗試新東西。但在生產/商業環境中，技術上的優勢並沒有超過整體上的劣勢，IMHO。當然，可以說這是不公平的，因為Spring取得今天的成就要比它長一個數量級，但這就是現實。


7、Quarkus離 "生產就緒 "還很遠......一些基本的功能，如資料庫連線池仍然是錯誤的（在簡單的資料庫重啟後，連線池一直是死的）......也許明年吧


8、Quarkus不僅僅是在生產中已經使用，而是在一些相當關鍵的系統中已經使用。例如，https://github.com/keycloak/keycloak。

雖然我毫不懷疑存在錯誤，但對我來說，它似乎可以用於生產。我們剛剛開始一項新的服務，在評估了一堆選項（Dropwizard、Boot、Micronaut等等）之後，選擇了Quarkus作為基礎。

DX是偉大的，相對於Spring這樣的基於執行時/反射的DI框架，我們真的很欣賞它沒有瘋狂的、抽象的、複雜的堆疊跟蹤，以及在編譯時而不是執行時捕獲問題。它是 "雲原生 "的這一事實使得部署到現代可擴充套件架構的工作更加簡單，而為Lambda部署建立原生映象的能力也是一個額外的好處（儘管在我們的決定中並沒有起到重要作用）。

無可否認，我們剛剛開始使用，還有很多東西需要學習，但到目前為止還沒有抱怨。時間會證明一切。
 

相關文章