MQ must be used more or less, after MQ access to the overall architecture is as follows:

You can see that with MQ, the upstream and downstream communication becomes the way it looks on the graph.

Another common solution for this cross-process communication is to use RPC services such as Dubbo.

In theory, cross-process communication scenarios using RPC can also be solved using MQ, and vice versa.

So why don’t you just use RPC or MQ to solve that?

This is all decided by the business scenario, business scenario aside to talk about architecture is playing hooligan! There is no almighty architecture, just the right architecture.

Let’s take a look at which scenarios are suitable for RPC and which are suitable for MQ.

RPC scenario

RPC is usually used in scenarios where upstream services need to rely on downstream service returns in real time.

Let’s take a login service as an example. The architecture diagram is as follows:

The login request initiated by the user is first accepted by the external WEB service, and then the WEB service invokes the user service to query the user information, and then compares the user password.

In other words, our WEB application needs to rely on the user information returned by the user service in real time. If it does not return, the login will fail.

If we replace this scenario with MQ, the WEB application sends the MQ message, and then the process ends, the WEB application cannot get the user information.

So for scenarios that rely heavily on downstream returns, using MQ has the following disadvantages:

  • Downstream results cannot be obtained directly from upstream
  • Adding an MQ component makes the system more complex

MQ scenario

A scenario where upstream does not care about downstream results

For example, in our third-party payment system, we need to calculate the handling fee for each successful payment.

We could obviously use RPC to complete the call in this scenario, but in reality, the payment system is the result of an unconcerned billing system, and there is no direct strong dependency between the two systems.

You can imagine that the user has actually received the bank card payment SMS, but the payment system failed because of the billing system, resulting in the external return is the result of failure. This is not acceptable to users. I paid for it, and you’re telling me it’s abnormal.

Therefore, for this scenario, using RPC calls directly is not sufficient because of the following points:

  • The overall call delay of the system increases
  • Downstream services are abnormal, and upstream services are affected. The two rely heavily on each other physically and logically
  • If a downstream system is added later, it needs to know the result of successful payment, and the upstream system needs to change its code. This can be very annoying for upstream situations. It has nothing to do with the upstream system, but the code needs to be modified.

Does it have to be MQ?

Not necessarily. For the scenario we mentioned above, we can actually use asynchronous RPC or thread pool to call RPC asynchronously.

After all, adding an MQ makes the system more complex, and we have to operate and maintain MQ alone, which is a lot of work for a small team.

But this way, still can’t solve, add a downstream system, the upstream system has to change the code embarrassment.

Add MQ decoupling

This scenario uses MQ decoupling, which has several advantages:

  • Task 1: The execution time of the upstream system is shorter
  • Task 2: Upstream and downstream logic decoupling, object understanding decoupling
  • Task 3: Most importantly, add a downstream service that requires only a subscription and no code changes for the upstream service

Data-driven scheduled task scenario

For example, payment companies need to check accounts every day, the main purpose is to verify whether the money receivable in their system is consistent with the payment channel end. The main process is divided into the following steps:

  • The account reconciliation file can be downloaded through Http or SFTP
  • The scheduled task parses the reconciliation file and then stores the reconciliation data
  • Check the local payment data with account reconciliation data in scheduled tasks

The above scheduled tasks are scheduled using spring-schedule. Assume that the download time of each scheduled task is as follows:

Of the three tasks shown above, task 2 depends on task 1, and task 3 depends on task 2.

When we used this model before, we usually ran into several problems:

  • Usually you can download the reconciliation file at 06:00, but sometimes the channel side reconciliation file is delayed, which will lead to the failure of task execution, so that the subsequent two scheduled tasks will also fail to execute
  • Suppose there is too much data in task 2, the execution time is too long, and the execution of task 3 is not finished. As a result, the full data in task 3 cannot be obtained, resulting in abnormal account reconciliation
  • The task execution time is too long. Procedure
  • If the time of task 1 is adjusted, the time of task 2 and task 3 May need to be adjusted

Use MQ decoupling

The architecture diagram with MQ decoupling is as follows:

In this way, as long as the scheduled task of task 1 starts on time, the MQ message is sent upon completion of task 1, and the task is started upon receipt of task 2, and the message is sent to MQ after completion. Task three is the same as task two

The advantages of this method are as follows:

  • As long as the downstream task receives the message, it can be executed immediately, without additional waiting, and the overall task execution time is shorter
  • If the upstream task time changes, you do not need to change the downstream task time. For our example, we just need the reality of task one

conclusion

MQ is not suitable for scenarios where upstream needs to be concerned about downstream returns.

Suitable scenarios for using MQ include:

  • A scenario where upstream does not care about downstream results
  • Data-driven scheduled task dependencies

Read three things ❤️

If you found this post helpful, I’d like to invite you to do three small favors for me:

  1. Likes, retweets, and your “likes and comments” are what drive me to create.

  2. Follow the public account “Java rotten pigskin”, irregularly share original knowledge.

  3. In the meantime, look forward to a follow-up article at ing🚀

  4. 【666】 Scan the code to obtain the learning materials package