一般的前言-如果你不需要就不要做。如果您正在处理大量的事件和事件备份问题等，引入队列系统可能是一个很大的改进。但是如果您不面临任何问题，则最好使用较低复杂性的直接服务通信。
回到您的问题—听起来您想抽象与队列的通信，因为您担心用不同的系统替换队列的工作—对吗？
在这种情况下，你可以按照你的建议去做——在中间开发一个新的服务。这伴随着物理服务的所有包袱（包括部署、扩展等）。
或者，第二种方法是编写一个客户机库，以您想要的方式抽象队列，并允许您在需要参与队列的所有服务中重用它。通过这种方式，您不必为此目的物理地部署另一个服务，但您仍然完全可以控制队列接口的外观，并且您只有一段代码可以合并更改（至少朝着队列的方向）。如果您确信库面向应用程序的一侧足够稳定，那么这将起作用。
但是，同样，当您不确定是否需要所有的复杂性时，不要在第一次迭代中执行这些操作(过度设计是一件危险的事情）

您应该创建一个接口，比如说“queue”，它提供您想要从kafka或rabbitmq、queue接口的create diff.impl like kafkaqueue和rabbitmqqueue获得的所有功能，并注入您想要在系统中使用的正确impl。
在这种情况下，如果使用新的队列系统，则不会更改现有代码
在这种情况下，创建另一个微服务是额外的开销

在服务体系结构中，使代码独立于通信通道的约束的正确方法是通过正确地建模自给自足的消息。历史上的例子是文档模式的wsdl、edifact、hateoas等。从这个Angular 来看，spring-boot和kafka的微服务只是大型机统治世界以来完成的相同老事情的不同实现。
基本上，如果你把你的应用程序看作是blackbox异步服务器；应用程序所做的一切就是接收事件并生成新的事件。在应用程序中如何引发事件并不重要。http请求、jms消息中的xml、kafka中的json等等——所有这些都只是传递事件的一种方式，应用程序的业务层应该只响应事件的内容。
因此，业务层通常是围绕一些定制模型/域构建的，这些模型/域作为有效负载交付。业务层由侦听器/生产者层调用/触发，侦听器/生产者层与通信通道（kafka侦听器、http侦听器等）通信。除了日志记录和强制执行安全之外，你不应该在应用程序中有通信通道逻辑。我看到过一些不幸的例子，业务逻辑是由发起jms连接或解析请求的url驱动的。如果您的代码中有这样的内容，那么您就无法正确地构造代码。
然而，说起来容易，实施起来难。有些人擅长这一级别的造型，有些人从不学习。
除了尝试和失败，没有别的学习方法。