Suomen Asiakastieto Oy 选择 Quarkus 进行微服务开发

Suomen Asiakastieto Oy 拥有多个不同的部门：风险决策、中小企业与消费者、客户数据管理、数字流程。房地产和抵押品信息部门在数字流程部门内运营，已将一个新应用程序部署到其应用程序服务器实例中，该应用程序在生产环境中运行时出现问题，影响了应用程序服务器的稳定性，进而影响了在其上运行的其他应用程序。这导致每次发生此异常情况时都需要重新启动应用程序服务器，从而导致意外停机和客户满意度下降。

因此，他们决定采用微服务架构，以便在其解决方案中引入更好的弹性和高可用性，这样，如果某个微服务或应用程序出现问题，也不会影响整个系统。因此，当开始开发他们的 PSD2 项目时，他们决定开始在 Thorntail 中实现微服务，Thorntail 是一个开源应用程序组装器——类似于 Spring Boot——它也实现了 MicroProfile，一个社区驱动的 Java 微服务开源规范。他们选择 Thorntail 是因为其功能和能力与他们熟悉的应用程序服务器能力非常接近。在生产中运行几个月后，他们了解了 Quarkus 及其创新的方法，该方法重新思考了适用于容器、云和 Kubernetes 的 Java。大约在同一时间，他们也了解了 Thorntail 的生命周期结束。他们继续希望开发新的微服务以及将其单体应用程序服务器分解为微服务，这使得他们更深入地评估了 Quarkus。

关于他们的单体应用，他们大约有 12 个 JBoss EAP 实例，每个实例运行着数十个应用程序。作为使整个系统更加分布式的首要步骤，他们决定开始将其中一些工作负载迁移到 OpenShift，方法是运行多个 JBoss EAP 实例，每个实例包含一个应用程序。结果，他们经历了高内存消耗。此时，他们开始寻找减少这些在 OpenShift 上运行的应用程序的占用空间的方法。

关于他们现有的 Thorntail 微服务（他们需要将其迁移到 Quarkus），他们注意到启动一个 Thorntail 容器大约需要 1 分钟才能启动。当他们将其迁移到 Quarkus 时，该服务现在在 0.4 秒内启动！通过这种改进的启动时间，他们可以更快地扩展服务，以便更快地准备好处理额外的流量，从而在高峰时段获得更好的客户体验，因为客户不必在浏览器上等待请求得到服务，例如。

事实上，在 Quarkus 投入生产之前，IT Development Finland Asiakasieto Oy 的解决方案架构师 Eero Arvonen 对微服务的 Thorntail 和 Quarkus 版本进行了比较分析。第一个图表显示了他们的 Thortail 微服务的原始版本（使用 JAX-WS）与同一微服务的不同 Quarkus 版本之间的比较。

下一个图表显示了与上一个图表中微服务版本的相同组合的性能和启动时间结果。

根据 Eero 的说法，“从 Thorntail 迁移到 JVM-Quarkus 非常简单，内存消耗下降了约 75%，而 CPU 消耗减少了约 70%。与此同时，吞吐量增加了 40%，从而缩短了响应时间。迁移到 Quarkus native，我们发现该应用程序以更好的吞吐量运行，即使只有 50MB 的内存，这也比 Thorntail 少 95%。我们还确定了不同 native Quarkus 设置之间的时空权衡：以 200MB 的内存而不是 50MB 的内存部署它将减少三分之二的 CPU 需求。因此，如果我们曾经需要在 OpenShift 集群中平衡 CPU 和内存，这将证明是有用的。”

他们非常喜欢 Quarkus 开发模式，也称为实时编码。在 Quarkus 之前，他们过去使用 JRebel 进行热替换，但它不可靠。根据 Eero 的说法，“Quarkus 开发模式迄今为止拥有更好的记录。” 现在他们正在编写新的微服务，他们已将其作为使用实时编码的最佳实践。使用 Thorntail，需要手动步骤来部署更改以进行尝试，而使用 Quarkus，更改会自动应用于正在运行的进程，以便开发人员可以立即测试应用程序。这使得开发人员的工作效率更高，因为他们可以更快地验证和排除代码故障。Eero 主动提供了一个小型内部 Quarkus 研讨会，这让开发人员对这项新的创新技术感到非常兴奋，“人们期待使用 Quarkus”，Eero 提到。Quarkus 让开发人员感到兴奋，这导致整个组织的其他开发人员将 Quarkus 用于他们的项目。

根据 Eero 的说法，“Quarkus 非常容易上手”。他认为，https://quarkus.net.cn/ 上的 Quarkus 指南非常好、透彻和全面，并提供了很好的代码示例。此外，他在 Quarkus 中找到了一个非常活跃的社区。当他们遇到问题时，他们能够在互联网上搜索错误消息并轻松地在线找到答案。此外，Quarkus 社区和 Quarkus 工程师非常活跃，即使在外部论坛上也能回答问题并帮助寻求帮助的人们。

尽管 Quarkus 非常出色，但这项不断发展的创新技术在某些方面仍有改进空间。例如，Eero 提到 Java API for XML Web Services (JAX-WS) 在 native 模式下不起作用。此外，SSL 默认情况下被禁用，但可用于 HTTP/S，他需要使用它并按照他发现复杂的配置说明使其工作。此外，他希望看到对当前反射配置方式的改进，配置起来非常耗时，因为他不得不使用试错方法才能使其工作。他希望看到一种使这种反射配置过程更容易执行的方法。

由于 Quarkus 采用了应用程序开发的封闭世界方法，因此在编写应用程序时需要稍微转变一下思路。例如，对于他们现有的应用程序，Asiakastieto 使用配置管理器在应用程序启动时读取配置信息（连接 URL、数据库连接字符串等）。由于使用 Quarkus，在 native 模式下，部分应用程序启动发生在构建时，他们必须重新配置配置管理器才能在应用程序运行时读取配置信息。尽管更改很容易进行，但它突出了理解在这种新范例下如何实现 Quarkus 应用程序的重要性。

如前所述，Asiakastieto Oy PSD2 项目已在 Thorntail 微服务中实现，当他们了解 Quarkus 时，决定将 Thorntail 微服务迁移到 Quarkus。在撰写本文时，在其 PSD2 应用程序的 7 个 Thorntail 微服务中，有一个已迁移到 Quarkus 并在生产环境中运行。

另有两个微服务已从 Thorntail 迁移到 Quarkus（native 模式），目前正在进行测试，并将在其 2020 年 2 月的下一次增量应用程序更新期间部署。

当他们一年半前开始他们的微服务计划时，Asiakastieto Oy 决定使用 Thorntail 作为他们 Java 微服务的主要技术。随着 Thorntail 即将停用以及 Quarkus 的推出，他们制定了一项新策略，即每个新项目都将在 JVM 模式下以 Quarkus 实现，并在可行的情况下在 native 模式下使用 Quarkus。目前已经有两个新项目正在 Quarkus 中实现，未来还将有更多项目。

有关 Quarkus 的更多信息