异步消息传递和微服务

Question

我正在计划开发一个基于微服务的架构应用程序，当我阅读Ronnie Mitra的书《微服务架构》时，我决定使用Kafka进行内部通信；马特·麦克拉蒂；迈克·阿蒙森；伊拉克利·纳达雷什维利说：

让微服务直接与消息代理（如RabbitMQ等）交互很少是个好主意。如果两个微服务通过消息队列通道直接通信，那么它们共享一个数据空间（通道），我们已经详细讨论了两个微服务共享一个数据空间的弊病。相反，我们可以做的是将消息传递封装在一个独立的微服务后面，该微服务可以以松散耦合的方式向所有感兴趣的微服务提供消息传递能力。

我使用Netflix Eureka进行服务注册和发现，Zuul作为边缘服务器和Hystrix。那么，在实践中，我如何实现这种微服务呢？如何使我的微服务独立于通信频道（在本例中为Kafka）？事实上，我直接与频道互动，所以我的出版商/订阅者和Kafka之间没有额外的一层。

更新日期：2018年2月6日

更准确地说，我们有两个微服务：一个是发布关于某个主题的新闻（activemq、kafka…）另一个微服务订阅了该主题，并对发送的消息执行一些操作。因此，我们有这些耦合到消息代理（到通道）的服务。。。我们的代码中有MessageBroker的api“Embeddeed”，例如，如果我们想更改MessageBroker，我们必须更改使用MessageBroker api的所有微服务。因此，他们建议使用一个微服务（在图中我假设是事件中心），它是各种消息的“调度器”。这样，它是唯一与通道交互的组件。

Answer 1

在服务体系结构中，使代码独立于通信通道的约束的正确方法是通过正确建模自给自足的消息。历史上的例子可能是文档模式的WSDL、EDIFACT、HATEOAS等。从这个角度来看，spring boot和kafka的微服务只是大型机统治世界以来完成的同一件老事情的不同实现。

本质上，如果您将应用视为黑盒异步服务器；应用所做的一切都是接收事件并生成新事件。如何在应用程序中引发事件并不重要。http请求、jms消息中的xml、kafka中的json等等，所有这些都只是传递事件的一种方式，应用程序的业务层应该只响应事件的内容。

因此，业务层通常围绕一些自定义模型/域进行结构化，这些模型/域作为有效载荷交付。业务层由监听器/生产者层调用/触发，监听器/生产者层与通信通道（Kafka监听器、超文本传输协议监听器等）进行对话。除了日志记录和加强安全性之外，应用程序中不应该有通信通道逻辑。我看到过一些不幸的例子，业务逻辑是由发起jms连接或解析请求的url驱动的。如果你的代码中有这样的代码，你就没有正确地构造你的代码。

然而，这说起来容易做起来难。有些人擅长这一级别的建模，有些人从不学习。

除了尝试和失败，没有其他学习方法。

Answer 2

你应该创建一个接口，比如“队列”，它提供你想要从Kafka或RabbitMQ中获得的所有功能，队列接口的创建不同于KafkaQueue和RabbitMQQueue，并注入你想要在系统中使用的正确的impl。

在这种情况下，如果使用新的队列系统，现有的代码将不会更改

在这种情况下，创建另一个微服务是额外的开销

Answer 3

一般性的前言——如果你不需要就不要做。如果您正在处理大量事件和事件备份问题等，那么引入队列系统可能是一个很大的改进。但是，如果您不面临任何问题，则最好使用较低的直接服务通信复杂性。

回到你的问题——听起来你想抽象你与队列的通信，因为你担心用不同的系统替换队列的努力——对吗？

在这种情况下，你可以按照你的建议去做——在中间开发一个新的服务。这是物理服务的全部负担（包括部署、扩展等）。

或者，第二种选择是编写一个客户机库，以您想要的方式抽象队列，并允许您在需要参与队列的所有服务中重用它。通过这种方式，您不必为此目的实际部署另一个服务，但您仍然可以完全控制队列接口的外观，并且您有一段代码来合并更改（至少是朝向队列的方向）。如果您确信面向库的应用程序可以足够稳定，那么这将起作用。

但是，同样，当您不确定是否需要所有的复杂性时，不要在第一次迭代中执行这些操作。（过度工程是一件危险的事情）