我正在计划开发一个基于微服务的架构应用程序，在阅读 Ronnie Mitra 的《微服务架构》一书时，我决定使用 kafka 进行内部通信；马特·麦克拉蒂；迈克·阿蒙森； Irakli Nadareishvili 他们说:
我使用 Netflix Eureka 进行服务注册和发现，使用 Zuul 作为边缘服务器和 Hystrix。
说了这么多，在实践中，我该如何实现那种微服务呢？如何使我的微服务独立于通信 channel (在本例中为 Kafka)？
实际上我直接与 channel 交互，所以我的发布者/订阅者和 kafka 之间没有额外的层。
更新 06/02/2018
更准确地说，我们有几个微服务:一个是发布关于某个主题(activemq、kafka...)的新闻，另一个微服务订阅该主题并对通过的消息执行一些操作。所以我们有这些服务耦合到消息代理(到 channel )......我们在我们的代码中“嵌入”了消息代理的 api，例如，如果我们想更改消息代理，我们必须更改所有使用消息代理 API 的微服务。因此，他们建议使用微服务(在图片中我假设是事件中心)，它是各种消息的“调度程序”。通过这种方式，它是唯一与 channel 交互的组件。
最佳答案
一般前言 - 如果您不需要，请不要这样做。如果您正在处理大量事件和事件备份问题等，引入队列系统可能是一个很大的改进。但是如果您没有遇到任何问题，那么直接服务通信的复杂性可能会降低一些。
回到你的问题 - 听起来你想抽象你与队列的通信，因为你担心用不同的系统替换队列的工作 - 对吗？
在这种情况下，您可以执行您的建议 - 在中间开发新服务。这伴随着物理服务的所有包袱(包括部署、扩展等)。
或者第二种选择是编写一个客户端库，以您想要的方式抽象队列，并允许您在需要参与队列的所有服务中重用它。通过这种方式，您不必为此目的物理部署另一个服务，但您仍然可以完全控制队列的接口(interface)应该是什么样子，并且您有一段代码来合并更改(至少朝着队列)。如果您确定库面向应用程序的一面足够稳定，这将起作用。
但是，再次强调，当您不确定是否需要所有复杂性时，请不要在第一次迭代中执行任何操作。 (过度设计是一件危险的事情)
关于java - 异步消息传递和微服务，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/48624757/