Stargate为何使用Quarkus作为API后端框架?


本文将介绍为什么 Stargate for Apache Cassandra 选择 Quarkus 而不是 Spring Boot 和 Micronaut 作为他们选择的 Java 框架背后的决策过程。

Stargate自 2020 年以来一直存在。在那段时间里,它帮助 Netflix、Yelp、Netlify、PrepLadder、SHIELD 等公司利用开源 NoSQL 数据库Apache Cassandra的强大功能来制作他们的数据通过 API 更容易访问。

星际之门将Apache Cassandra变成了一个云数据服务。你可以通过HTTP APIs和Drivers将应用程序、服务和功能连接到Cassandra,为数据平面注入无限的规模和速度。除了支持Cassandra的传统CQL接口外,你还可以使用Stargate v2的高性能gRPC实现,实现无驱动化它和本地数据库驱动程序一样快,而且很多网络配置都是由gRPC自动完成的,因此更容易使用(和学习)。

放弃Dropwizard
Stargate v1使用Dropwizard作为其暴露HTTP端点的框架,但该项目不再得到很好的维护,现在有更多的现代框架,具有更优越的功能。

Stargate v2版也是一个机会,可以把API的因素剔除,使其服务独立。由于Stargate是开源的,这些变化将有助于内部和外部的人使用API,而不需要对Cassandra有深入了解。

剔除API的因素也意味着可以独立发布和部署变化,而不是等待它们被捆绑在一起。

框架评估要求

  • 学习曲线必须是宽松的。最后一件事是引入一个新的框架,没有人愿意采用它并陷入一些奇怪的困境。这个框架必须是整个团队都能支持并毫不费力地接受的东西。
  • 该框架需要有许多开箱即用的功能。这样,就可以立即取得进展,而无需花费额外的开发资源。特别是,该框架必须有出色的gRPC支持,因为这是Stargate 在通信方面非常依赖的东西。
  • 全面的性能。从启动时间到运行时间的性能都必须被考虑,以帮助开发者体验。出于同样的原因,对反应性的支持也很重要。

三个Java框架是领先者。Spring Boot、Micronaut和Quarkus:
为了帮助选择理想的框架,我们创建了一个表格,列出了每个框架的所有功能,并根据它们对星际之门的影响进行适当的打分。我们在所需的JDK、依赖性管理、配置、Docker镜像构建、配置、反应式编程API、可观察性、安全性和社区参与方面比较了每个框架。

Spring Boot是应用程序开发的一个热门选择,但很快就发现自己不是一个选择,因为。

  • 缺乏对gRPC的官方支持。
  • 本机镜像构建仍处于实验模式。
  • 而Spring Boot在检索数据方面很强,但这并不是Stargate 的要求。

因此,这是一场Micronaut和Quarkus之间的单挑。

那么谁是赢家呢?

这是一个接近的决定,因为它们提供了许多类似的功能。最终,决定性的因素是:

  • gRPC支持 - 失败的框架并不支持所有的gRPC功能。
  • JDK 17 - 在决策时,他们并不完全支持Java 17,这对Java语言的特性如Z垃圾收集和GraalVM本地图像编译非常重要。
  • 集成测试--我们需要一个能够处理自定义环境和依赖关系(如Cassandra集群)的布线的框架。
  • 可观察性支持--一个完整的开箱即用的指标和跟踪支持,包括HTTP和gRPC流量。
  • 社区 - 一个充满活力的社区对于我们所选择的框架的持续健康发展至关重要。

基于所有这些因素,获胜的框架是Quarkus。

Quarkus
在完全采用Quarkus之前,我们进行了一次试用,以获得亲身感受,我们发现它是Stargate 的正确框架。Quarkus有优秀的文档,充满了所有扩展的详细指南,让你清楚地了解如何实现你的目标,并清楚地显示配置属性。

Quarkus的另一个优点是扩展之间的兼容性。你可以激活一起工作的不同扩展,创造一个统一的体验。你不需要担心将扩展配对在一起时的问题。

Quarkus的一个不错的功能是开发模式。开发模式允许你改变你的应用源、资源或配置,然后自动反映在你运行的应用中。这样,你可以快速得到反馈,看看你的改变可能对你的应用程序产生了什么影响。