Quarkus vs. SpringBoot - Reddit

22-05-05 banq

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部署建立原生镜像的能力也是一个额外的好处(尽管在我们的决定中并没有起到重要作用)。

无可否认,我们刚刚开始使用,还有很多东西需要学习,但到目前为止还没有抱怨。时间会证明一切。
 

猜你喜欢