Vodafone Greece 用 Quarkus 替换 Spring Boot

沃达丰希腊公司是希腊第二大电信公司,为超过 600 万用户提供固定和无线电话服务。

沃达丰希腊公司在本地和云端运行许多应用程序,因此云资源消耗成本对他们来说非常重要。他们的架构中的一个组件是数字体验层 (DXL),这是一个基于 Kubernetes 的软件,通过提供基于 TMF 规范的易于使用的 REST API,充当沃达丰核心系统(基于 SOAP 的通信)和客户端(Web/Mobile)之间的中间件(https://www.tmforum.org/)。其目标是成为沃达丰未来几年数字服务的支柱。它的组件利用 MongoDB、Kafka Streams 和 Redis 等技术,将旧服务的响应速度提高 800% 以上,同时将它们转换为 REST 友好的通用 API。DXL 是使用 Spring Boot 实现的,完全在云端运行,他们一直在经历大量的内存资源消耗和长时间的启动,因此他们开始寻找减少这些的方法。

沃达丰希腊公司关心的另一个关键领域是应用程序启动时间过长,尽管沃达丰希腊公司可以为 DXL 分配更多的云资源以缩短启动时间,但这将意味着更高的云成本。因此,他们开始寻找优化 DXL 的方法,使其消耗更少的云资源。

除了 DXL 之外,沃达丰希腊公司还使用 Spring Boot 运行大部分微服务。目前,他们在开发和生产中运行的微服务中有 80% 是基于 Spring Boot 的,但他们也有 4 个 Node.js 微服务。

他们如何选择 Quarkus

他们寻找 Spring Boot 替代品的选择过程的主要标准是开发者效率、更低的云资源消耗和更短的应用程序启动时间。他们认为后者对云资源消耗成本以及用户体验的改善有很大的影响。

他们考察并评估了其他技术和框架,例如其他可本地编译的框架、Node.js 和 Vert.x。他们认为 Node.js 对他们来说不是一个好的选择,因为他们会将 Java 开发者学习和将 Java 应用程序迁移到 Javascript 的负担加重。一些框架也没有通过,因为他们希望有大型的可靠的支持者和赞助商。另一个本地可编译的框架没有被选中,因为它无法编译 MongoDB 驱动程序 - 当时不支持在本地模式下使用 MongoDB 驱动程序,并且无法跳过 MongoDB 驱动程序中无法编译为本地的部分。他们几乎选择了 Vert.x,因为它具有出色的上下文传播能力和出色的性能。然而,当他们在 2019 年 4 月了解到 Quarkus 时,了解到它在堆栈中包含了 Vert.x 并提供了内存和启动时间优化,他们决定选择 Quarkus。根据沃达丰希腊公司 DXL 技术负责人 Christos Sotiriou 的说法,Quarkus “似乎提供了我们需要的性能提升,同时拥有良好的支持者(Red Hat)并依赖于经过实战检验的技术”。2019 年 6 月,沃达丰希腊公司首次成功部署了微服务,该服务依赖于 Quarkus 中有限的一组重写的通用库。

选择 Quarkus 而不是竞争技术的另一个原因是开发者编写自己的扩展的能力。此外,该项目的高度活跃特性,例如社区成员数量、项目 star 数、Quarkus 开发者对社区问题的快速回复和修复,以及 Red Hat 开发者通过项目沟通渠道彻底回答技术问题的数量,都是他们选择 Quarkus 的积极指标。最后,他们对 Red Hat 的信任及其在软件市场中的信誉让他们确信,他们选择了 Quarkus 是正确的选择,Quarkus 的赞助商是 Red Hat。

解决方案

一旦他们确定了前进的道路,沃达丰希腊公司首先开始将他们的通用内部库从 Spring Boot 迁移到 Quarkus。他们的通用库涵盖了跨领域的关注点,例如

  • 日志

  • 安全

  • 数据库连接

  • Kafka 连接

  • 分布式日志记录

根据 Christos 的说法,“使用 Spring Boot 实现分布式日志记录将非常困难,而使用 Quarkus,创建这个新的通用库是可行和可行的。Quarkus 中设置标头传播并在微服务的入站-出站请求上执行操作的方法允许比 Spring Boot 更好的可重用性,至少在我们的用例中,并且允许我们为我们的跨国团队提供更简单的设置”

截至今天,他们大约有 15 个 Quarkus 微服务,其中 5 个于 2019 年 9 月底投入生产。在工作量方面,有 2 名开发人员专门负责处理这 5 个现在在 JVM 模式下运行的微服务。目前,他们的团队正在努力在未来 3 个月内交付 20 个微服务。值得一提的是,根据他们的经验,他们的 Spring 开发者很容易掌握 Quarkus Java 堆栈,因为“从 Spring Boot 迁移到基于 CDI 的框架不需要太多精力”,正如 Christos 所说。

虽然 Quarkus 包括 Spring API 兼容性,但沃达丰希腊公司没有计划使用它,因为根据 Christos 的说法,“在微服务中混合两种编程模型没有意义”。为了保持代码的简洁,沃达丰希腊公司“仅使用 Quarkus 结构,而不会用 Spring 语法混淆”,正如 Christos 所指定的那样。对于他们的需求,Quarkus 堆栈已经提供了他们需要的一切,所以根本不需要任何 Spring Boot。

好处

沃达丰希腊公司在使用 Quarkus 后看到了许多好处。其中之一是 JVM 模式下的内存资源消耗减少了一半。此外,启动时间在没有任何优化的情况下减少到几乎四分之一。值得一提的是,其中许多微服务很复杂,因为它们“有很多 Kafka 和数据库连接”,正如 Christos 所描述的那样。

他们的日志记录系统使用 Kafka,消耗大量内存,因为它处理大型消息并将它们转换为 JSON。例如,一些微服务在使用 Spring Boot 时需要 1 GB 的 RAM。相比之下,对于生产,他们现在可以使用 512 MB 的 RAM 部署 Quarkus 微服务。“对于 80 个微服务,这是一个很大的节省!” Christos 强调说,并补充说“Quarkus 默认提供的东西(不尝试优化)比 Spring 在优化后(注意依赖关系,使用 JVM 选项等)提供的轻 50%-60%(在 JVM 模式下)”。在启动时间方面,很大一部分时间都花在等待消息代理和数据库接受连接上,这使得 Spring Boot 微服务的启动时间约为 50 秒。但是使用 Quarkus 微服务,启动时间不到四分之一(14 秒)。

他们体验到的开发者效率提升的巨大程度出乎意料,令人惊喜。首先,他们意识到从 Spring Boot 迁移到基于 CDI 的框架不需要他们的 Spring 开发者付出太多努力,从而导致了很小的学习曲线。其次,Quarkus 实时编码功能(又名开发模式)的使用导致开发者生产力的提高,Christos 将其描述为“拥有一件非常好的事情”。例如,每个开发周期由 1 到 2 个 sprint 组成(1 个 sprint = 2 周),具体取决于正在开发的逻辑的复杂性,并且使用 Quarkus,他们看到“相对于 Spring Boot,开发者生产力提高了 30% 到 40%,这是对于一位前 Spring Boot 开发者而言”,根据 Christos 的说法。

另一个让他们印象深刻的 Quarkus 功能是 Quarkus 使用企业 Java 的方式的有效性,例如,结合上下文传播对异步方法使用 CDI 的简洁方式。微服务调用其他微服务,然后由其他微服务聚合返回的信息并不少见,并且这通过 MicroProfile 上下文传播和 MicroProfile 响应式消息传递扩展在 Quarkus 中轻松实现。事实上,“MicroProfile 是我们喜欢 Quarkus 作为开发工具的一个很好的理由”,Christos 说。

下一步是什么

就下一步而言,沃达丰希腊公司现在拥有的微服务数量仅涵盖了他们计划做的很小一部分。他们希望将现在的数量翻倍,换句话说,将微服务数量和致力于此计划的开发者数量翻倍。为此,他们计划在未来三个月内发布 20 个 Quarkus 微服务。根据 Christos 的说法,随着他们的成长,“编排和开发者生产力将变得对他们消耗的资源更加重要”

目前,他们在连接到 MongoDB 时以 JVM 模式运行 Quarkus,但他们正在考虑将来使用带有 MongoDB 的本地编译。当沃达丰希腊公司几个月前开始使用 Quarkus 时,它不包括 MongoDB 的扩展,但 Quarkus 现在确实包含一个 MongoDB 客户端扩展,他们可以利用它。此外,他们计划使用更多的 Quarkus 扩展,例如来自 MicroProfile Fault Tolerance 的断路器,并更广泛地采用 MicroProfile 响应式消息规范。

此外,尽管使用 Quarkus,他们已经在 JVM 模式下运行它,将内存消耗和启动时间减少了一半以上,但他们计划将来以本地模式运行他们的 Quarkus 微服务,以获得更好的内存消耗和启动时间。

有关 Quarkus 的更多信息