Is your feature request related to a problem? Please describe.

In the current service graph, I find that the representation of relationships when making asynchronous service calls via message middleware is not intuitive, and I would prefer to be able to visualize the message middleware nodes.

Describe the solution you'd like

In the scenario where services are produced and consumed through the message queue middleware, the final graph only shows the invocation relationship between the producer and the consumer. It hides the message middleware node. This is intuitively no different from the use case where the client requests the server directly.

I think there may be the following benefits if we show message middleware type nodes:

• The topology of the diagram is closer to reality and the original asynchronous call relationship is shown more clearly. The producer service is only responsible for writing data to the message middleware and the consumer is only responsible for reading messages from the message middleware.
• In the edge scenario, if the message is not consumed within the timeout period, the current indicator is discarded. If we use a similar approach for DB requests, this call information from the producer service to the message middleware is preserved.

In conclusion, I would suggest to display the message middleware directly on the service graph, and as far as the technical implementation is concerned, using a similar approach to the way current DB requests are handled seems to help us achieve this.

What do you guys think?

(To give an example of rabbitmq, below is a graph of the current state vs. the state after the requirements are implemented)

Now

Then

Describe alternatives you've considered

Additional context