Welcome to follow our wechat official account: Shishan100
My new course ** “C2C e-commerce System Micro-service Architecture 120-day Practical Training Camp” is online in the public account ruxihu Technology Nest **, interested students, you can click the link below for details:
120-Day Training Camp of C2C E-commerce System Micro-Service Architecture
Previously on
Here are some of the questions an interviewer might ask about message-oriented middleware during an interview:
- Why did you introduce message-oriented middleware into your system architecture?
- What are the disadvantages of introducing message-oriented middleware in a system architecture?
For answers to these two questions, see the previous two articles:
- Why did you introduce message-oriented middleware into your system architecture?
- What are the disadvantages of introducing message-oriented middleware into a system architecture
After these two questions, different styles of interviewers may ask different questions.
For those of you who have been working for a long time, you may want to start digging into the technical details of the message-oriented middleware used by the candidate’s company, such as the architecture and core source code of RocketMQ.
The other style, however, looks at your project and business first, like this:
- Which specific business scenario did message-oriented middleware land on your production project?
- What are the technical challenges of this business scenario?
- Why must message-oriented middleware technology be used in this business scenario?
- How do you use message-oriented middleware?
Good! In this article, let’s talk about the second style.
2. Introduction to business scenarios
We’ll land in a particular scenario of a particular business system to see how messaging middleware is used and what the effect is.
For business scenarios, let’s take the e-commerce business that everyone is familiar with as an example. In order to facilitate understanding, some abstractions and simplifications are made here.
Consider a business process for placing an order. For example, if you place an order, you need to do several things:
- Update the order status to “Waiting for delivery” (20ms)
- Commodity inventory deduction (time: 100ms)
- Increase member points (80ms)
- Complimentary coupon (50ms)
- Warehouse scheduling delivery (tens of seconds).
Explain: the above link, in order to facilitate everyone to understand, simplified. In a truly complex e-commerce system, the overall link and business process will be many times more complicated than this, and the time consuming is definitely not as simple as the above.
As usual! Let’s take a look at the entire business process using a hand-drawn diagram:
As shown above, in this order placing business process:
Update order status (20ms) + deduct goods inventory (100ms) + increase member points (80ms) + bonus coupon (50ms) = 250ms.
That’s over 200 milliseconds for just those four processes.
The time of more than 200 milliseconds is very fast for the user’s ordering experience. It is almost completed in an instant without too much pause. That is to say, the user can see his placing a successful order all of a sudden.
But what if you add that dispatch warehouse shipment?
It requires reading a lot of data, using a multi-warehouse/multi-bit scheduling algorithm, and communicating with a C/S warehouse system on the network, so let’s assume that this process may take tens of seconds.
Once the link of scheduling storage and delivery is added to the ordering process, it may cause users to wait for the page to be blocked for dozens of seconds before they will see the prompt of successful ordering, which will result in poor user experience.
According to the previous article “One of the Java Advanced Interview series” why did you introduce message-oriented middleware into your system architecture? The claim. For this scenario, it is perfectly appropriate to use messaging middleware for asynchronous invocation.
In other words, the order service simply sends a message to MQ, then the warehouse service consumes the message and slowly executes the scheduling algorithm to assign the goods to the warehouse.
In this way, the tens of seconds of warehouse scheduling and delivery can be removed from the ordering process. This ensures that the ordering process takes just over 200 milliseconds.
As for the warehousing scheduling and delivery process that takes tens of seconds, we can execute it slowly in an asynchronous way, which will not affect the user’s ordering experience.
The above process, we also take a picture, we intuitively feel:
Three, the initial landing
Good! Let’s assume that you haven’t used message-oriented middleware in actual production. Let’s start at 0 and see how it works.
For those who have used message-oriented middleware in production, you may as well take a look at it as a review.
Take RabbitMQ as an example. If you are using RabbitMQ, how do you install and deploy this middleware?
RabbitMQ’s official documentation provides very detailed installation and deployment steps, which can be installed locally on your laptop or on your company’s servers.
Now assuming that you have consulted the documentation and installed RabbitMQ, what is the code level for introducing RabbitMQ and sending and receiving messages in your system?
Here is some HelloWorld code and some simple example diagrams to show how RabbitMQ sends and receives messages.
For many of you who have used MQ in real production, this code may seem too simple.
However, considering that many beginners may not have ever used MQ or even heard of messaging middleware for a while, I feel that the demo code and manual drawings are still necessary.
Good! After looking at the code, at this point, we can visualize the communication between two services using a diagram.
You can start more than one order service to push messages to a RabbitMQ queue.
You can also start multiple repositories, each of which uses round-robin polling and consumes a portion of the messages from the RabbitMQ queue.
In the figure above, the ordering service is known in MQ jargon as “Producer” (Producer), meaning that the service is responsible for producing messages to MQ.
The warehousing service is called ** “Consumer” in MQ jargon, meaning that the service is specifically responsible for consuming and processing messages from MQ.
At this point, the asynchronous communication architecture is ready to go.
Well, so far, although this code still exist many problems, but it doesn’t matter, in general we have given some not too familiar with the classmate of MQ technology, image from a relatively easy to understand simplified electric business scenarios, through the level of the HelloWorld sample code and manual drawing, the MQ landing run up this technology.
Furthermore, you can use the examples in this article to ask yourself: is there a similar business scenario in your own project where MQ can be used?
Then find a way to implement MQ technology in your own projects to do some asynchronization and improve the performance of the core process.
In this way, when the job interview in the future, can do with ease, have their own set of things to say.
END
Dude, what happens if the consumer of messaging middleware goes down? [Stay tuned]
If there is any harvest, please help to forward, your encouragement is the biggest power of the author, thank you!
A large wave of micro services, distributed, high concurrency, high availability of original series of articles is on the way
Please scan the qr code belowContinue to pay attention to:
Architecture Notes for Hugesia (ID: Shishan100)
More than ten years of EXPERIENCE in BAT architecture