问题
We have a use case where we have two microservices, Microservice A pushes a long-running task to Microservice B.
Microservice B starts processing the task and keeps updating the status of the task. Now Microservice A has to constantly poll Microservice Bfor an update on the status of the task.
We don't have queues in our current setup.
So, We thought of creating a web socket between Microservice A and Microservice B so that Microservice B can push the status updates to Microservice A. Would this design violate any of the principles of Web sockets and also will it be a better approach compared to constant polling?
回答1:
The most recommended option would be to add a queue :
- That would reduce the coupling between microservice A and microservice B
- That would allow Microservice C which will also be interested in the task status/result to be aware of it without any change for Microservices B
If you still go for websocket, you would have to consider cases of scalability (what if you have two instances of MicroserviceB, which one to call), failures (what if one service fails, who re-runs the socket...), and a few others. That's why it's not the best option to do asynchronous calls in a Microservices environnement.
回答2:
Apache Pulsar has the ability to work as a message broker and has a WS interface for sending messages to and listening on topics. I haven't tried it myself yet...but I will test to use it for sending and listening on events in different types of microservices. Pulsar in it self is scaleable and allows persistent messaging and can be installed and executed on Kubernetes for example. But I have only read about it...now I must try it myself :).
来源：https://stackoverflow.com/questions/54512595/can-we-use-web-sockets-for-communication-between-microservices