use*_*934 41 rest apache-kafka microservices kafka-consumer-api spring-kafka
如今在微服务世界中,我在我的工作场所看到很多使用 kafka 消息传递的设计,当您可以使用微服务之间的 rest api 调用获得类似的结果时。从技术上讲,您可以完全停止使用 rest api 调用,而是使用 kafka 消息传递。我真的很想知道最佳实践,优缺点,微服务之间何时使用 api 调用,何时使用 kafka 消息传递。
让我们举一个现实生活中的例子:
我有库存服务和供应商服务。日常供应商服务调用供应商 API 来获取新项目,这些需要转移到库存服务中。项目数最多可达 10,000 个对象。
对于这个用例,最好是:
从供应商 API 获取新数据后,调用库存服务的 REST API 来存储新项目。
从供应商 API 获取新数据后,将它们作为消息发送到 kafka 主题,供库存服务使用
您会选择哪种方式以及考虑什么
Jav*_*cal 38
Kafka - 发布和订阅(只处理管道,工作完成后会通知)
REST - 请求和等待响应(按需)
Kafka - 发布一次 - 订阅n次(由n 个组件)。
REST - 请求一次,得到一次响应。成交。
Kafka - 数据存储在主题中。随时来回搜索(偏移量),直到保留主题。
REST - 一旦响应结束,它就结束了。手动使用数据库来存储处理后的数据。
Kafka - 拆分处理,将中间数据存储在中间主题中(为了速度和容错)
REST - 获取数据,一次处理所有数据,或者如果您希望将其分解,请不要忘记照顾您自己的中间数据存储。
Kafka - 发出请求的人通常对响应不感兴趣(如果发送消息的响应除外)
REST - 我发出请求意味着我通常期望得到响应(不仅仅是您收到请求的响应,而是对我有意义的响应,例如一些计算结果!)
你的数据流了吗?
如果数据源源不断,并且您有一个管道可以执行,那么 Kafka 是最好的。
你需要一个请求-响应模型吗?
如果用户请求某事并等待响应,那么 REST 是最好的。
Kafka(或任何其他流媒体平台)通常用于管道,即我们有前向数据流的地方。
数据进入 Kafka,从那里经过组件 1、 组件 2等,最后(通常)进入数据库。
为了按需获取信息,我们需要一个数据存储(一个数据库),我们可以在其中查询和获取信息。在这种情况下,我们提供了一个 REST 接口,用户可以调用它并获取他们想要的数据。
关于你的例子,
日常供应商服务调用供应商 API 来获取新项目,这些需要转移到库存服务中
问题和答案
您的供应商 API 是否使用 REST?
然后你需要拉取数据并推送到Kafka。从那里您的库存服务(或此后的任何其他服务)将订阅该主题并执行其处理逻辑。
这里的优点是您可以将需要供应商数据作为消费者的任何其他服务添加到供应商主题。
此外,即使在您的库存服务处理之后,供应商数据也始终为您服务。
如果为此使用 REST,则需要为每个需要供应商数据的组件调用供应商 API,这在与 Kafka 一起使用时变得微不足道
您要查询库存吗?
通过 Kafka 处理后将其存储在数据库中,并在此基础上提供 REST。这是必需的,因为 Kafka 通常是一个日志,要使数据可查询,您需要一些数据库。
微服务架构提倡独立自主的服务,可以自行运行。让我们了解为什么我们需要消息队列?
HTTP协议是同步的
人们普遍误解 HTTP 是异步的。Http 是同步协议,但您的客户端可以异步处理它。例如,当您使用 http 调用任何服务时,您的 http 客户端将安排在后端线程上(异步)。但是,http 调用将一直等待,直到超时或响应返回,在此期间,http 调用链正在同步等待。现在,如果您一次有数百个请求,您可以想象同步调度了多少个 http 调用,并且您可能会运行套接字。
AMQP
在微服务架构中我们更喜欢AMQP(高级消息队列协议)。这意味着服务会将消息放入队列并忘记它。这是真正的异步传输协议,因为一旦您的服务将消息放入队列中,您的服务就完成了,感兴趣的服务将选择这些消息。
这种类型的协议是首选,因为即使其他服务关闭,您也可以放心扩展,因为它们最终会获取消息/事件/数据。
所以这实际上取决于您的具体情况。HTTP 很容易实现,但无法很好地扩展它们。消息服务面临着自己的挑战,例如消息顺序和工作人员,但这使得架构可扩展,并且是首选方式。对于写操作,总是首选队列,对于读操作,您可以使用 HTTP,但请确保您没有执行一个长链,其中一个服务调用另一个服务,另一个服务又调用另一个服务。
希望有帮助!
| 归档时间: |
|
| 查看次数: |
14704 次 |
| 最近记录: |