Kafka Msg VS REST 调用

如今在微服务世界中,我在工作场所看到了很多使用卡夫卡消息的设计,而在微服务之间使用 rest api 调用可以获得类似的结果。从技术上讲,您可以完全停止使用 rest api 调用,而是使用 kafka 消息传递。我真的很想知道最佳实践,利弊,什么时候在微服务之间使用 api 调用,什么时候使用卡夫卡消息。

让我们举一个现实生活中的例子:

我有库存服务和供应商服务。每天供应商服务调用供应商 API 来获取新的商品,这些商品需要移动到库存服务中。项的数量可以多达10,000个对象。

对于这个用例,最好是:

  1. 从供应商 API 获得新数据后,调用库存服务的 REST API 来存储新项目。

  2. 从供应商 API 获得新数据后,将它们作为消息发送到一个卡夫卡主题,供库存服务使用

你会选择哪种方式,考虑的因素是什么

32122 次浏览

有几篇文章很容易理解卡夫卡在 Microsercices 扮演的角色。

微服务-apache-kafka-域驱动设计

从旅程到事件的驱动

用卡夫卡建立微服务生态系统

建设-服务-主干-事件

如果你需要进一步的帮助,让我知道。乐意帮助。

微服务体系结构提倡独立和自治的服务,它们可以自己操作?

HTTP 协议已同步

人们普遍误解 HTTP 是异步的。Http 是同步协议,但是客户端可以异步处理它。例如,当您使用 http 调用任何服务时,您的 http 客户端将调度在后端线程上(异步)。然而,http 调用将一直等待,直到超时或响应返回,在此期间,http 调用链同步等待。现在,如果您一次有数百个请求,您可以想象有多少个 http 调用被同步调度,并且您可以运行套接字。

AMQP

在微服务体系结构中,我们更喜欢 AMQP (高级消息队列协议)。这意味着服务丢弃队列中的消息并忘记它。这是真正的异步传输协议,因为一旦您的服务在队列中丢弃消息,它就完成了,并且感兴趣的服务将挑选这些消息。

这种类型的协议是首选的,因为即使其他服务停机,您也可以毫不担心地进行扩展,因为它们最终将获得消息/事件/数据。

所以这取决于你的具体情况。HTTP 很容易实现,但是无法很好地扩展它们。消息服务带来了自身的挑战,比如消息的顺序和工作者,但是这使得体系结构具有可伸缩性,并且是首选的方式。对于写操作总是更喜欢队列,对于读操作,您可以使用 HTTP,但是要确保您没有执行一个长链,其中一个服务调用另一个服务,而该服务调用另一个服务。

希望能帮上忙!

要点(对于那些只想要要点的人)

    • Kafka -发布和订阅(只需处理管道,完成任务后会通知)

    • REST -请求和等待响应(随需应变)


    • 卡夫卡 -发布一次-订阅 N次(按 N组件)。

    • REST -请求一次,获得响应一次。


    • 卡夫卡 -数据存储在主题中。随时向前向后查找(补偿) ,直到主题被保留。

    • REST -一旦响应结束,它就结束了。


    • 卡夫卡 -分割处理,将中间数据存储在中间主题中(用于速度和容错)

    • REST -获取数据,一次处理所有数据,或者如果您希望分解它,不要忘记关注 你自己的中间数据存储。


    • Kafka -发出请求的人对 回应不感兴趣(除了发送消息时的响应)

    • REST -我正在使请求意味着我 典型的期望一个响应(不仅仅是您已经收到请求的响应,而是对我有意义的东西,例如一些计算结果!)

问答风格

您的数据流吗? < br/> 如果数据源源不断,而且您有一个 管道要执行,那么卡夫卡是最好的。

您需要 请求-响应模型? < br/> 吗? 如果用户请求某些东西,并且他们等待响应,那么 REST 是最好的。

卡夫卡(或任何其他流媒体平台)通常用于管道,即我们有 向前流动的数据。

数据来到卡夫卡,从那里经过 组件1, 组件2等,最后(一般来说)到达数据库。

为了获得信息 随叫随到,我们需要一个数据存储(一个数据库) ,在那里我们可以查询和获得它。在这种情况下,我们提供了一个 REST 接口,用户可以调用它并获得他们想要的数据。


关于你的例子,

每天供应商服务调用供应商 API 来获取新的项目和 这些需要转移到库存服务

问与答

您的供应商 API 使用 REST 吗?

然后你需要 的数据和 用力卡夫卡。 从那里您的库存服务(或其他任何服务)将订阅该主题,并执行其处理逻辑。

这里的优点是,您可以向供应商主题添加任何其他需要供应商数据作为使用者的服务。

此外,即使在库存服务处理了供应商数据之后,它也总是在那里等着您。

如果您为此使用 REST,那么您需要为每个需要供应商数据的组件调用 Vendor API,这在与 Kafka 一起使用时就变得微不足道了

您希望查询库存吗?

通过卡夫卡处理后,将其存储在数据库中,并在此基础上提供 REST。这是必要的,因为卡夫卡通常是一个日志,使数据可查询,你需要一些数据库。

卡夫卡的主要好处:

对于每个服务的直接 REST 调用——如果有 N 个服务需要彼此通信,那么大约是 N ^ 2/2个连接。您可能还需要在获得大量请求的某些服务之前构建一些负载平衡器,也可能需要在服务中构建一个队列/缓冲系统来对其请求进行排队(lol)

对于卡夫卡,你只需要 N 个主题。根据定义,它已经提供了它的排队系统。

卡夫卡的主要缺点:

服务不等待请求响应。一旦响应出现在主题中,就很难将响应与请求关联起来。