Comparison between remote call service (RPC) and message queue and their applicability/Inapplicability

In most cases, the question "which of the two products should be used in a given scenario" is easily determined and does not require much discussion.

Why should I discuss it out:

• Some scenarios will be vague and I think they can all be used. In this case, you need to know the product disadvantages, rather than the advantages.
• Some new users may think that the product functions can be replaced.

The difference between the two is briefly described here.

System Structure

1234567891011121314

RPC system structure: + ---------- ++ ---------- +| Consumer | <=> | provider |+ ---------- ++ ---------- +The service provided by the provider called by consumer.Message Queue System Structure: + -------- ++ ------- ++ ---------- +| Sender | <=> | queue | <=> | receiver |+ -------- ++ ------- ++ ---------- +The sender sends a message to the queue. The receiver obtains the message from the queue for processing.

Features

In terms of architecture, the difference between RPC and message is that message has an intermediate node message queue, which can store messages.

Message features

• The message queue stores the request pressure and gradually releases it so that the processor can process it at its own pace.

• Message Queue introduces a new node, so that the system reliability will be affected by the Message Queue node.

• Message Queue isAsynchronousUnidirectional. Designed as YesNoWaitMessage Processing is complete.

Therefore, for Synchronous return, message queue is the direction.

PRC features

• Synchronous calling: RPC is a natural and intuitive method for scenarios where you want to wait for the returned results/processing results.
  # RPC can also be an abnormal call.
• Due to waiting for results, consumer (client) will consume threads.

If it is used in asynchronous RPC mode, the consumption of consumer (client) threads can be removed. However, messages/requests cannot be saved as messages, and the pressure is directly transmitted to the service provider.

Applicable scenarios

• RPC is suitable for scenarios where synchronous results are expected.
• If you want to make the call simple, the RPC and RPC operations are based on the interface, which is simple and simulates local calls. Asynchronous programming is complicated.
• Message Queue is not required when the speed of the processing end (RPC consumer and message sender) is limited.

As the business grows, some processing end processing capacity will become a bottleneck and will be transformed from Synchronous calls to asynchronous messages.

This transformation actually involves adjusting the business usage.

For example, after an operation page is submitted, the processing result will be displayed on the next page. After the asynchronous message is modified, the next page will be changed to "Operation submitted, and will be notified after completion ".

Non-applicable scenarios

Synchronous RPC call uses message queue to transmit call Information. The above analysis shows that the sending end is waiting and occupies resources at an intermediate point. It becomes complicated, but there is no equivalent benefit.

You can do this for calls whose return value is void, because in fact, this call usually does not need to be synchronized for processing results, as long as it is guaranteed to be processed. (RPC ensures that the call return process is complete.NoYes .)

The return value is a void call. When a message is used, the message usage method wrap is used as a service call (the service call method is simple and based on the service interface ).