英文:
Communication between microservice using messages and REST
问题
我有两个微服务，A和B（使用Express和TypeScript）。当B创建一个对象b并引用来自微服务A的对象a时，需要先验证其是否存在。
我考虑实现本地存储，当A创建或删除一个对象时，在队列（Kafka）中发布一条消息，订阅者会更新缓存。这也允许微服务之间进行异步通信，例如，如果一个微服务想要在另一个微服务中创建一个需要一些时间来创建的资源。但是我希望保留API Rest，以便在需要公开或需要同步通信时使用。
我考虑了三种方法：
- 创建两个服务，一个是REST API，一个是队列的消费者（例如Kafka），它们都在同一域上运行。
- 运行API，并在后台或异步中运行队列的消费者。
- 微服务只消费消息，创建一个接收请求并将其转换为消息的REST API，等待响应消息并返回响应。
英文:
I have two Microservices A and B (express and typescript). When B creates and object b referred to an object a from Microservice A, it needs to verify that exists first.
I thought in implementing a local storage, when A create or delete an object publish a message in a queue (Kafka) and subscribers update the cache. Also allows async communication between microservices, for example if one microservice wants to create a resource in another that takes time to be created. However I want to conserve API Rest to expose publicly or when I need a sync communication.
I thought three approaches:
-
Make two services, one a rest api, one consumer of the queue (for example kafka) both working on same domain.
-
Running the api, and in background or async the queue consumer.
-
The microservice just consume messages, create a rest api that receives requests and transform into messages, waiting the response message and returning the response
答案1
得分: 1
没有什么阻止Express应用程序同时运行Kafka消费者。我在自己的项目中正在这样做（尽管NestJS已经包含了我建议使用的Kafka支持）
但是，是的，您可能需要考虑基于后端数据库/存储的CQRS和/或Outbox架构模式
对于服务之间的通信，您可以使用gRPC、REST、Kafka或任何其他消息队列...
英文:
There's nothing preventing an express app from also running a Kafka consumer. I'm doing it in my own projects (although NestJS has included Kafka support that I'd recommend instead)
But yes, you may want to consider a CQRS and/or Outbox architecture pattern, depending on backend database / storage
For communications between services, you could use gRPC, REST, Kafka or any other message queue...
答案2
得分: 0
方法1：分离的REST API和KubeMQ队列消费服务
优点： 责任分离明确，可扩展性和灵活性更好。
缺点： 管理两个服务略微复杂。
建议： 使用KubeMQ进行微服务之间的异步通信，允许A发布对象创建或删除事件，B消费并更新其缓存。这保持了责任的清晰分离，同时又可以从异步通信中受益。
这种方法利用了KubeMQ的能力，实现微服务之间的无缝通信，同时在需要时仍然保持REST API可用于同步交互。
英文:
For your scenario involving microservices A and B, where B needs to verify the existence of an object referred to by A:
Approach 1: Separate REST API and KubeMQ Queue Consumer Services
Pros: Clear separation of concerns, better scalability, and flexibility.
Cons: Slightly more complex to manage two services.
Recommendation: Use KubeMQ for asynchronous communication between microservices, allowing A to publish object creation or deletion events, and B to consume and update its cache. This maintains a clean separation of responsibilities while benefiting from asynchronous communication.
This approach leverages KubeMQ's capabilities for seamless communication between microservices while still keeping the REST API available for synchronous interactions when needed.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论