Lufthansa Technik AVIATAR 通过迁移到 Kubernetes 原生 Quarkus，显著节省了云资源
汉莎技术公司是全球最大的独立航空公司维护、修理和大修 (MRO) 服务提供商，为航空业运营一个名为 AVIATAR 的 SaaS 数字平台。该平台通过使用数据更好地组织和安排维护，帮助航空公司避免延误和取消。该公司使用基于 Red Hat 企业开源软件的混合云基础设施构建和运营 AVIATAR。
在过去的 3 年里，AVIATAR 的业务一直在快速增长，他们需要满足客户不断增长的需求。为此，他们不得不将开发团队从最初的 5 名开发人员扩展到目前的 100 多名。随着他们的成长，他们意识到一个庞大的团队并不是组织软件开发工作的最有效和高效的方式，因为由于整个系统中的许多相互依赖关系，许多开发人员不得不花时间等待彼此的工作完成。为了解决这个问题，他们决定将开发从一个团队分成几个跨职能团队。与此同时，他们也开始努力使新创建的较小开发团队更加独立，方法是赋予每个团队自主运行自己的服务的权力。这导致他们演变为微服务架构，其中他们的大部分微服务都基于 Spring Boot 和 Java EE。截至本文撰写之时，他们已经从最初的 10 个服务增加到 100 多个。
小型和自主的开发团队已经能够负责自己的服务，从开发到生产，以实现更大的敏捷性并更快地响应业务需求。
现有服务对云资源的高消耗
汉莎技术公司在 Azure 上的 OpenShift 上运行他们的微服务，当他们寻找不同的方法来扩展他们的开发工作时，他们也在寻找节省云资源消耗的方法。在迁移到微服务的过程中，他们注意到微服务消耗了大量的内存和计算云资源。出于高可用性和紧急程序的目的，他们在云上运行每个微服务的至少 3 个实例，这意味着对于每个微服务，都有 3 倍的云资源消耗率。例如，他们的一个微服务消耗 ½ 个核心加上每个实例 1 GB 的 RAM，这意味着在云上以 HA 方式运行时（3 个实例）需要 1.5 个核心和 3 GB 的 RAM。
使用 Quarkus 优化云资源消耗
AVIATAR 数字产品部门的自动化和平台架构产品负责人 Thorsten Pohl 在 2019 年 4 月的 Red Hat Summit 上首次听说了 Quarkus 及其优势。在其众多优势中，引起他兴趣的是其低内存消耗和快速的首次响应时间，无论是在 JVM 模式还是在原生模式下。他将这些信息带回 AVIATAR，他们决定尝试一下。他们的技术委员会推荐了两个初始微服务用于 Quarkus 试用。第一个将是一个名为“客户配置”服务的新微服务，第二个将是“服务发现”服务，它将是从在应用程序服务器中运行的服务迁移到 Quarkus。
客户配置服务
该服务供客户设置自己的设置，例如所需的预测级别。该服务针对他们的托管客户，并且被选择使用 Quarkus 开发，因为它风险较低。从他们的角度来看，如果该服务出现故障，对客户不会产生重大影响。它由 2 名开发人员使用 Quarkus 0.20 在一个 sprint（大约 3 周）内开发，他们计划将其升级到 Quarkus v1.x。该服务目前在生产环境中以原生模式运行。
服务发现服务
服务发现服务用于允许 AVIATAR 包含的微服务之间的自动发现。它被认为是高风险的，因为如果它崩溃，会对客户产生重大影响。此外，该服务的原始版本在应用程序服务器中作为高可用性服务在生产环境中运行，消耗了大量云资源。Quarkus 版本的此服务已在开发环境中以原生模式运行约 3 个月，没有出现任何问题，并且在 2020 年 1 月 18 日，它被部署到生产环境以替换在应用程序服务器上运行的实例。还应该提到的是，这个 Quarkus 服务以 JVM 模式启动，因为它使用了 MongoDB，并且在其开发开始时没有 MongoDB 客户端 Quarkus 扩展。但是，一旦 MongoDB 客户端 Quarkus 扩展可用，他们就能够将整个服务切换到原生模式。这说明了 Quarkus 开源社区项目的快速创新和新贡献。
为什么不选择 Spring Boot？
汉莎技术公司认为 Quarkus 非常适合他们以无服务器模式运行服务的旅程。他们有许多服务不经常被调用，但由于高可用性要求，他们仍然需要始终启动并运行每个服务的 3 个实例，这导致了高云资源消耗成本。他们计划将这些很少访问的服务转换为 Function-as-a-service 调用，以便可以按需调用它们，从而减少云消耗。如果他们使用 Spring Boot，启动时间会太长，使得无法以无服务器模式使用它。
同样，他们在使用 Quarkus（以及其 GraalVM 的使用）时体验到了更低的内存和计算云资源消耗，并且根据 Thorsten 的说法，“使用 Quarkus，他们可以在不牺牲服务的可用性和响应时间的情况下运行 3 倍密集的部署”，因为更密集的部署来自这两种技术的结合。
他们的开发人员是具有 Java EE 经验的 Spring Boot 开发人员，因此 Quarkus 的学习曲线非常小，因为它的语法和方法“与我们的开发人员已经在做的事情非常接近，并且他们很熟悉。这是一个很大的好处”，Thorsten 肯定地说。
关于 Quarkus 中最近引入的 Spring API 兼容性功能，Thorsten 说“他们可能会在将当前的 Spring Boot 微服务迁移到 Quarkus 时使用 Quarkus 中的 Spring API 兼容性。但是，对于开发新的微服务，他们计划仅直接使用 Quarkus API，因为在 Quarkus 中使用另一个 API 会很尴尬。”
Quarkus 的优势
在 Quarkus 为汉莎技术公司提供的众多优势中，Thorsten 提到“他们可以将云资源成本降低三倍。” 由于使用 Quarkus 可以在每个核心上实现更高的密度，OpenShift 也是如此。例如，他们有一个微服务消耗 ½ 个核心加上每个实例 1 GB 的 RAM，这意味着在云上以 HA 方式运行时（3 个实例）需要 1.5 个核心和 3 GB 的 RAM。当使用相同微服务的 Quarkus 版本时，其消耗量为每个实例 200 毫核心加上 200-400 MB 的 RAM。这转换为 0.6 个核心加上 600 MB – 1.2 GB 的 RAM，用于 3 个微服务实例的 HA 部署“他们可以在不牺牲服务的可用性和响应时间的情况下运行 3 倍密集的部署”，Thornsten 重申。这些类型的优化只能通过 Quarkus 和 GraalVM 的共生组合来实现。
Thorsten 还将 Quarkus 实时编码功能描述为“非常棒的一件事”。他们的许多应用程序都有基于 Web 的用户界面，并且“进行更改并立即重新加载页面是一个很棒的功能”，Thorsten 肯定地说。另一个好处，前面已经提到过，是他们的开发人员（他们是有 Java EE 经验的 Spring Boot 开发人员）所经历的小型 Quarkus 学习曲线。使这成为可能的是 Quarkus 中包含的技术堆栈，它由 Kubernetes 原生微服务的最佳技术和熟悉技术组成。AVIATAR 开发人员使用的一些 Quarkus 扩展包括：Java Web Token (JWT)、JAX-RS、MongoDB 客户端、MicroProfile Rest Client、Keycloak（安全性）、Hibernate ORM（用于关系数据库）、MicroProfile Metrics 和 MicroProfile Health Check。
展望未来
他们计划根据其技术委员会的指导，使用 Quarkus 开发新服务。一般来说，对于新服务，他们希望首先处理对客户风险较低或没有风险的服务。他们还计划将其服务发现服务升级到 Quarkus v1.x 并将其部署到生产环境，这实际上发生在 2020 年 1 月 18 日。最后，他们将直接使用 Quarkus API，并且为了将 Spring Boot 服务迁移到 Quarkus，他们可能会利用 Quarkus Spring API 兼容性功能。
他们期待通过在其服务中使用 Quarkus 堆栈来继续优化其云资源消耗。
有关 Quarkus 的更多信息
-
Quarkus 网站：https://quarkus.net.cn
-
Quarkus GitHub 项目：https://github.com/quarkusio/quarkus
-
Quarkus Twitter：https://twitter.com/QuarkusIO
-
Quarkus 聊天：https://quarkusio.zulipchat.com/
-
Quarkus 邮件列表：https://groups.google.com/forum/#!forum/quarkus-dev
