我正在评估 vert.x 框架，看看是否可以减少使用 Spring Boot 开发的微服务之间基于 Kafka 的通信。
问题是：
我可以更换吗
- 带有 vert.x 事件总线的 Kafka 和
- 带有基于 vert.x 的 verticle 的 Spring Boot 微服务
为了快速回答，我想说这取决于您的需求。
是的，事件总线是使用异步和非阻塞范例处理微服务 verticle 之间本机通信的好方法。
但在某些情况下您可能需要：
- 处理一些常见的企业模式，例如重播机制、消息持久性、事务性读取
- 能够按时间顺序处理某种消息
- 处理并非全部使用相同框架/工具包甚至编程语言编写的多种微服务之间的通信
- 处理可靠性、弹性和
当所有消费者/微服务/verticles 死亡时的故障恢复
- 处理动态水平可扩展性并监控消费者/微服务/verticle
- 能够使用部署在多数据中心和多区域中的单个集群
在这些情况下，我更愿意选择 Apache Kafka，而不是本机事件总线或旧的令人着迷的 JMS 兼容系统。
并不禁止根据您的实际需求在同一个微服务架构中同时使用eventbus和kafka。例如，您可以让一个 kafka 消费者组读取 kafka 主题来处理扩展、监控、故障恢复和回复机制，然后通过 eventbus 处理子 verticle 之间的通信。
我将澄清一点可扩展性和监控部分，并解释为什么我认为使用 Kafka 在本机事件总线上处理这个问题更简单，并且使用 vert.x 进行集群模式：Kafka 让我们实时了解（通过 JMX 指标 https://www.datadoghq.com/blog/monitor-kafka-with-datadog/和describe命令）：
- 对应主题的“滞后”
未读消息数
- 每个组中正在收听某个主题的消费者数量
- 每个消费者影响的主题的分区数
- 输入/输出指标
因此，可以使用 ElasticStack 或 Prometheus+Grafana 解决方案来监控这些指标并使用它们来处理动态可扩展性（当您知道需要临时增加消费者数量时，例如根据滞后指标和消费者数量）分区和主机的 cpu/ram/swap 指标）。
要回答第二个问题 vert.x 还是 SpringBoot 我的回答不是很客观，但我会投票给 vert.x，因为它尤其是它的简单性。我有点厌倦了 Spring 工厂及其庞大的抽象层，这些抽象层在堆积如山的注释下隐藏了很多问题，从而触发了堆积如山的 AOP。
此外，在微服务的 Java 世界中，还有 SpringBoot 的其他替代方案，例如 Microprofile 的不同实现（刺尾项目 https://www.youtube.com/watch?v=eJBqo8iKBHI例如）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
