Debezium发布历史51
原文地址： https://debezium.io/blog/2019/03/14/debezium-meets-quarkus/
欢迎关注留言，我是收集整理小能手，工具翻译，仅供参考，笔芯笔芯.
Debezium 遇见 Quarkus
三月 14, 2019 作者： Jiri Pechanec
quarkus 示例 微服务 apache-kafka
上周Quarkus的发布引发了 Java 社区的极大兴趣：它采用同类最佳的 Java 库和标准精心打造，允许基于 GraalVM 和 OpenJDK HotSpot 构建 Kubernetes 原生应用程序。在这篇博文中，我们将演示基于 Quarkus 的微服务如何通过 Apache Kafka 使用 Debezium 的数据更改事件。为此，我们将了解如何将我们最近关于发件箱模式的文章中的发货微服务转换为基于 Quarkus 的服务。
Quarkus 是一个 Java 堆栈，旨在开发基于 Java 平台的云原生应用程序。它结合并紧密集成了成熟的库，如 Hibernate ORM、Vert.x、Netty、RESTEasy 和 Apache Camel，以及来自Eclipse MicroProfile计划的 API，如Config或Reactive Messaging。使用 Quarkus，您可以使用命令式和反应式风格开发应用程序，还可以根据需要组合这两种方法。
它旨在显着减少内存消耗并缩短启动时间。最后但并非最不重要的一点是，Quarkus 支持 OpenJDK HotSpot 和 GraalVM 虚拟机。使用 GraalVM 可以将应用程序编译为本机二进制文件，从而进一步减少资源消耗和启动时间。
要了解有关 Quarkus 本身的更多信息，我们建议您查看其优秀的入门指南。
使用 Quarkus 消费 Kafka 消息
在演示发件箱模式的原始示例应用程序中，有一个基于 Thorntail 的微服务（“发货”），它消耗 Debezium 连接器生成的事件。我们使用名为“shipment-service-quarkus”的新服务扩展了该示例。它提供与“shipment-service”相同的功能，但作为基于 Quarkus 而不是 Thorntail 的微服务实现。
这使得整体架构看起来像这样：
图片来自于官网原文
发件箱模式概述
要将原始服务改造为基于 Quarkus 的应用程序，只需要进行一些更改：
Quarkus 目前仅支持 MariaDB，不支持 MySQL；因此我们包含了服务正在写入的 MariaDB 实例
用于反序列化传入 JSON 消息的JSON -P API目前无法在没有 RESTEasy 的情况下使用（请参阅问题 #1480，该问题应该很快就会修复）；因此代码已被修改为使用 Jackson API
使用 MicroProfile 定义的Reactive Messaging API代替 Kafka Consumer API来接收来自 Apache Kafka 的消息；作为该 API 的实现，使用SmallRye 项目提供的 API ，它捆绑为 Quarkus 扩展
虽然前两个步骤只是技术问题，但响应式消息传递 API 对原始消费者中的轮询循环进行了很好的简化。消费来自 Kafka 主题的消息所需要做的就是用 注释一个方法@Incoming，当新消息到达时它将自动调用：
@ApplicationScoped
public class KafkaEventConsumer {
@Incoming("orders")
public CompletionStage onMessage(KafkaMessage message)
throws IOException {
// handle message...
return message.ack();
}
}
“orders”消息源通过 MicroProfile Config API 进行配置，该 API 将其解析为从原始发件箱示例中已知的“OrderEvents”主题。
构建过程
构建过程与以前基本相同。现在不再使用 Thorntail Maven 插件，而是使用 Quarkus Maven 插件。
使用以下 Quarkus 扩展：
io.quarkus:quarkus-hibernate-orm：支持 Hibernate ORM 和 JPA
io.quarkus:quarkus-jdbc-mariadb：支持通过 JDBC 访问 MariaDB
io.quarkus:quarkus-smallrye-reactive-messaging-kafka：支持通过 MicroProfile Reactive Messaging API 访问 Kafka
他们还引入了一些其他扩展，例如quarkus-arc（Quarkus CDI 运行时）和quarkus-vertx（由反应式消息支持使用）。
此外，还需要进行两项更改：
native添加了一个名为的新构建配置文件；这用于使用 Quarkus Maven 插件将服务编译为本机二进制映像
native-image.docker-build运行构建时启用系统属性；这意味着本机映像构建是在 Docker 容器内完成的，因此不必在开发人员的计算机上安装 GraalVM
所有繁重的工作都是由 Quarkus Maven 插件完成的，该插件在pom.xml中配置如下：
shipment ... io.quarkus quarkus-maven-plugin ${version.quarkus} build ... native io.quarkus quarkus-maven-plugin ${version.quarkus} native-image true false 配置 与任何 Quarkus 应用程序一样，运输服务是通过application.properties文件配置的：quarkus.datasource.url: jdbc:mariadb://shipment-db-quarkus:3306/shipmentdb
quarkus.datasource.driver: org.mariadb.jdbc.Driver
quarkus.datasource.username: mariadbuser
quarkus.datasource.password: mariadbpw
quarkus.hibernate-orm.database.generation=drop-and-create
quarkus.hibernate-orm.log.sql=true
smallrye.messaging.source.orders.type=io.smallrye.reactive.messaging.kafka.Kafka
smallrye.messaging.source.orders.topic=OrderEvents
smallrye.messaging.source.orders.bootstrap.servers=kafka:9092
smallrye.messaging.source.orders.key.deserializer=org.apache.kafka.common.serialization.StringDeserializer
smallrye.messaging.source.orders.value.deserializer=org.apache.kafka.common.serialization.StringDeserializer
smallrye.messaging.source.orders.group.id=shipment-service-quarkus
在我们的例子中它包含
发货服务写入数据的数据源（基于 MariaDB）的定义，
消息源的定义，由“OrderEvents”Kafka 主题支持，使用给定的引导服务器、反序列化器和 Kafka 消费者组 ID。
执行
Docker Compose 配置文件已通过两项服务进行了丰富：MariaDB 和新的基于 Quarkus 的运输服务。因此，在docker-compose up执行时，会同时启动两项运输服务：最初的基于 Thorntail 的服务和使用 Quarkus 的新服务。当订单服务收到新的采购订单并通过发件箱表将相应的事件导出到 Apache Kafka 时，两个发货服务都会处理该消息，因为它们使用不同的消费者组 ID。
性能数据
这些数字绝对不科学，但很好地表明了基于 Quarkus 的本机应用程序和 JVM 上运行的 Thorntail 服务之间的数量级差异：
夸库斯服务 刺尾服务
内存[MB]
33.8
第1257章
开始时间 [毫秒]
260
5746
应用程序包大小 [MB]
54
131
内存数据是通过htop实用程序获得的。测量启动时间直到打印有关应用程序准备就绪的消息。与所有性能测量一样，您应该根据您的设置和工作负载进行自己的比较，以深入了解特定用例的实际差异。
概括
在这篇文章中，我们成功地证明了可以在使用 Quarkus Java 堆栈编写的 Java 应用程序中使用 Debezium 生成的事件。我们还表明，可以提供二进制图像形式的应用程序，并提供粗略的性能数据，证明可以显着节省资源。
如果您想亲自体验将 Java 微服务部署为本机映像的美妙之处，可以在 Debezium 示例存储库中找到实现的完整源代码。如果您有任何问题或反馈，请在下面的评论中告诉我们；期待您的回音！
非常感谢 Guillaume Smet 审阅本文的早期版本！