Kafka Msg VS REST通话 [英] Kafka Msg VS REST Calls

查看:82
本文介绍了Kafka Msg VS REST通话的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

如今,在微服务领域,我看到了很多使用kafka消息传递的工作场所设计,当您使用微服务之间的rest api调用可以达到类似的结果时.从技术上讲,您可以完全停止使用rest api调用,而可以使用kafka消息传递.我真的很想知道最佳实践,它的优缺点,何时在微服务之间使用api调用,何时使用kafka消息传递.

Nowadays in microservice world, i’m seeing alot of design in my workplace that uses kafka messaging when you can achieve similar results using rest api calls between microservices. Technically you can stop using rest api calls altogether and instead use kafka messaging. I really want to know the best practice, pros and cons, when to use api calls between microsevices, when to use kafka messaging.

让我们举一个真实的例子:

Lets put a real life example:

我有一个库存服务和一个供应商服务.日常供应商服务会调用供应商API来获取新项目,这些新项目需要移到库存服务中.项目数最多可以达到10,000个对象.

I have an inventory service and a vendor service. Everyday vendor service calls the vendor API to get new items and these need to be moved into inventory service. The number of items can be up to 10,000 objects.

对于此用例,最好:

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

  1. After getting new data from vendor API, call REST API of inventory service to store the new items.

从供应商API获取新数据后,将它们作为消息发送给kafka主题,供库存服务使用

After getting new data from vendor API, send them as message to a kafka topic, to be consumed by inventory service

您会选择哪种方式以及要考虑的因素

Which way would you choose and what is the consideration

推荐答案

要点(对于只需要要点的人)

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

    • Kafka - Publish & Subscribe (just process the pipeline, will notify once the job is done)

REST -请求&等待响应(按需)

REST - Request & Await response (on-demand)


    • Kafka -发布一次-订阅 n 次(通过 n 组件).

    • Kafka - Publish once - Subscribe n times (by n components).

REST -请求一次,获取一次响应.交易结束.

REST - Request once, get the response once. Deal over.


    • Kafka -数据存储在主题中.找回只要您想保留主题,都可以进行第四次( offsets ).

    • Kafka - Data is stored in topic. Seek back & forth (offsets) whenever you want till the topic is retained.

REST -响应结束后,响应结束.手动使用数据库来存储处理后的数据.

REST - Once the response is over, it is over. Manually employ a database to store the processed data.


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

    • Kafka - Split the processing, have intermediate data stored in intermediate topics (for speed and fault-tolerance)

REST -获取数据,立即处理所有数据,或者如果您希望对其进行分解,请不要忘记照顾您的OWN 中间数据存储.

REST - Take the data, process it all at once OR if you wish to break it down, don't forget to take care of your OWN intermediate data stores.


    • Kafka -发出请求 通常 的人对响应不感兴趣(除了响应(如果发送了消息)

    • Kafka - The one who makes the request typically is not interested in a response (except the response that if the message is sent)

REST -我发出的请求意味着我 通常 期望得到答复(而不仅仅是收到的答复)请求,但是对我来说有意义的东西,例如一些计算结果!)

REST - I am making the request means I typically expect a response (not just a response that you have received the request, but something that is meaningful to me, some computed result for example!)

问答式

您的数据正在流传输吗?
如果数据持续流传并且您需要执行管道,那么Kafka是最好的选择.

Q&A style

Is your data streaming?
If the data keeps on coming and you have a pipeline to execute, Kafka is best.

您是否需要一个请求-响应模型?
如果用户请求某些内容并且他们等待响应,那么REST是最好的.

Do you need a request-response model?
If the user requests for something and they wait for a response, then REST is best.

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

Kafka (or any other streaming platform) is typically used for pipelines i.e where we have forward flow of data.

数据进入Kafka,然后从那里通过 component1, component2 等,最后(通常是 )到达数据库中.

Data comes to Kafka and from there it goes through component1, component2 and so on and finally (typically) lands in a database.

按需获取信息,我们需要一个数据存储(数据库),可以在其中查询和获取它.在这种情况下,我们提供了一个REST接口,用户可以调用该接口并获取他们想要的数据.

To get the information on-demand we need a data store (a database) where we can query and get it. In such a case we provide a REST interface which the user can invoke and get the data they want.

关于您的示例,

每天供应商服务都会调用供应商API来获取新商品,并 这些需要转移到库存服务中

Everyday vendor service calls the vendor API to get new items and these need to be moved into inventory service

问题与解答;答案

您的供应商API是否使用REST?

然后您需要数据并将其到Kafka. 从那里,您的库存服务(或之后的其他任何服务)将订阅该主题并执行其处理逻辑.

Then you need to pull the data and push to Kafka. From there your inventory service (or any other service thereafter) will subscribe to that topic and execute their processing logic.

这样做的好处是,您可以将任何需要将卖方数据作为使用者的其他服务添加到卖方主题.

此外,即使在库存服务处理完之后,供应商数据也始终会存在.

Moreover, the vendor data is always there for you even after your inventory service processed it.

如果您为此使用REST,则需要为每个需要供应商数据的组件调用供应商API,当与Kafka一起使用时,供应商数据变得不重要

是否要查询库存?

在通过Kafka处理后将其存储在数据库中,并在此之上提供REST.这是必需的,因为Kafka通常是一个日志,要使数据可查询,您将需要一些数据库.

Store it in a database after processing through Kafka and provide a REST on top of this. This is needed because Kafka is typically a log, to make the data query-able you would need some database.

这篇关于Kafka Msg VS REST通话的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆