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
“We begin this article by addressing common interview questions about message-oriented middleware, as well as some common technical issues with MQ middleware. If the interviewer sees your experience with MQ middleware in your resume, he or she is likely to be asked: What kind of messaging middleware does your company use in its production environment? Why introduce message-oriented middleware into your system? What are the benefits and disadvantages of introducing message-oriented middleware? Okay, let’s take it one by one!
What kind of message-oriented middleware is used in your production environment?
Start by saying what messaging middleware your company uses, such as RabbitMQ, and give you an initial analysis of the different MQ middleware technologies.
For example, ActiveMQ is an old message middleware, which has been widely used by many domestic companies with powerful functions.
However, the problem is that ActiveMQ can not be confirmed to support the complex scene of high concurrency, high load and high throughput of Internet companies, which is rarely implemented in Domestic Internet companies. What’s more, some traditional enterprises use ActiveMQ to make asynchronous call and system decoupling.
Then you can talk about RabbitMQ. The benefits of RabbitMQ are high concurrency, high throughput, high performance, and a very sophisticated backend management interface to use.
In addition, it supports clustering, high availability deployment architecture, high reliable messaging support, and more complete functionality.
And through the investigation, the domestic major Internet companies landed large-scale RabbitMQ cluster to support their own business case, domestic various small and medium-sized Internet companies using RabbitMQ practice is also more.
In addition, RabbitMQ has an active open source community, with frequent iterations, bug fixes and optimizations, so the company has adopted RabbitMQ.
RabbitMQ does have one drawback, however. It is based on The Erlang language itself, which makes it difficult to analyse the source code, and to customise it further, requiring a solid Erlang background.
Then we can talk about RocketMQ, which is open source and has been tested by ali’s production environment for high concurrency and high throughput, while also supporting special scenarios such as distributed transactions.
RocketMQ is based on the Java language, which makes it easy to read source code in depth and solve online production problems at the source level, including secondary development and modification of source code.
The other is Kafka. Kafka provides significantly less functionality for messaging middleware than the previous MQ middleware offerings.
But Kafka’s advantage is that it is designed for ultra-high throughput scenarios such as real-time log collection, real-time data synchronization, and real-time data computation.
So Kafka is used in big data with real-time computing technologies such as Spark Streaming, Storm and Flink. However, it is rarely used in traditional MQ middleware usage scenarios.
Why did you introduce message-oriented middleware into your system architecture?
To answer this question, you need to talk about common usage scenarios for message-oriented middleware.
Then, in light of your own system usage scenarios, describe what problems have been solved by introducing message-oriented middleware in your system.
1) System decoupling
Suppose you have system A, and system A produces A core data, and now downstream systems B and C need this data.
That’s easy. System A just calls the interface between system B and system C and sends data to them.
The whole process is shown below.
But now what if system D, system E, system F, system G, etc., and a dozen other systems gradually need this core data? As shown in the figure below.
We can not think this is a joke, a large-scale system, often split into dozens or even hundreds of subsystems, each subsystem and corresponding to N more than services, these systems and systems have a complex relationship network.
If one system produces a piece of core data, it may be needed by countless other systems downstream to implement various business logic.
At this point, if you adopt the above pattern to design the system architecture, you will definitely be annoyed to death by your classmates in charge of system A.
First, someone comes to him and asks him to send data to A new system H, and the student in system A has to modify the code and put in that code the flow of calling the new system H.
Later, system B is an old system and will go offline. Tell the students of System A: Don’t send me the data, and then system A will modify the code again and no longer send it to system B.
And what if one of the downstream systems suddenly goes down? Does system A throw an exception in its calling code? The student of system A will receive an alarm saying that it is abnormal, and as A result, he has to care which downstream system is down.
Therefore, in the actual system architecture design, if all adopt this system coupling way, in some scenarios is absolutely inappropriate, the system coupling degree is too serious.
Moreover, it is not the call of core link but some non-core scenarios (such as the above data consumption) that lead to system coupling, which will seriously affect the development and maintenance efficiency of upstream and downstream systems.
Therefore, in the above system architecture, MQ middleware can be used to achieve system decoupling.
System A will send A copy of its core data to MQ, and any downstream system that is interested in it can consume it by itself. If it is not needed, it can cancel the data consumption, as shown in the figure below.
2) Asynchronous invocation
Suppose you have A system call link. System A calls system B, which usually takes 20ms. System B calls system C, which usually takes 200ms. System C calls system D, which generally takes 2s, as shown in the following figure.
Now the biggest problem is: a request from the user is extremely slow, because it takes 20ms + 200ms + 2000ms (2s) = 2220ms to complete a link, that is, more than 2 seconds.
But in reality, system A on the link calls system B, and system B calls system C, and these two steps add up to 220ms.
Because of the introduction of the step of system C calling system D, the final link execution time is more than 2 seconds, which directly reduces the link call performance by 10 times, which is the culprit of the slow link execution.
At this point we can think about whether we can pull system D out of the link and make an asynchronous call? There are many business scenarios that allow asynchronous invocation.
For example, if you order takeout, click your order and then pay for it, the account will be deducted, the order will be created, and the merchant will be notified to prepare the food for you.
Next, do you need a rider to deliver your meal? The process of finding riders requires a set of complex algorithms to realize scheduling, which is time-consuming.
But in fact, it is OK to complete the dispatch of riders a little later than a few seconds, because it is not necessary to find a good rider for you immediately at the moment you pay, nor is it necessary.
So can we take the step of finding a rider to deliver your food out of the link and make it asynchronous, even if the delay is tens of seconds, but as long as you find a rider to deliver your food within a certain time range.
Does that make it super fast to order takeout? Once the payment is made, you simply create the order, charge your account, and tell the vendor to prepare your meal immediately, which can take a few hundred milliseconds.
Then the background asynchrony may cost you tens of seconds to find a rider to deliver food through the scheduling algorithm, but this step does not affect our fast order.
Of course, we are not saying that the technical architecture of those familiar takeout platforms must be so realized, but with a common example in life to illustrate it.
Therefore, the above link is also the same. If the business process supports asynchrony, can we consider pulling out the calls from system C to system D to make them asynchrony instead of synchronous calls in the link?
In this way, the implementation idea is system A -> system B -> system C, directly cost 220ms directly successful.
System C then sends a message to the MQ middleware, which is consumed by system D and then slowly asynchronously performs the 2s business process. In this way, the execution performance of the core link is improved by 10 times.
The whole process is shown below.
3) Flow peak cutting
Suppose you have a system that normally receives hundreds of requests per second. The system is deployed on an 8-core 16GB machine, and the normal processing is OK. Hundreds of requests per second can be easily resisted.
However, as shown in the picture below, during the peak, thousands of requests per second suddenly come, and there is an instantaneous traffic peak. At this time, your choice is to build 10 machines to withstand the instantaneous peak of thousands of requests per second?
If the instantaneous peak is only half an hour a day, then it drops to a few hundred requests per second. If you deploy many machines online, then each machine can handle dozens of requests per second. Isn’t that a bit of a waste of machine resources?
Most of the time, a few hundred requests per second, one machine is enough, but to cope with the daily instantaneous peak, the deployment of 10 machines is only useful for half an hour a day, otherwise it is a waste of resources.
But if you deploy just one machine, it can cause a sudden spike that overwhelms your system because you can’t handle the thousands of requests per second.
At this point we can use MQ middleware for peak load shaving. With a layer of MQ deployed in front of all machines, messages can easily be received with a few hundred requests per second.
Once the instantaneous peak is reached, thousands of requests per second can be piled into MQ and slowly processed and consumed by that machine.
Once the peak is over, and after a while, the backlog in MQ is consumed.
This is a typical use of MQ, with limited machine resources to accommodate high concurrency requests, and is suitable if the business scenario allows asynchronous peak-cutting, a backlog of requests in MQ at peak times, and then the peak times are over and the backend system is consumed within a certain period of time.
The next episode:
About the third question: what are the benefits and disadvantages of introducing message-oriented middleware?
We’ll be looking at the next article, “Brother, what are the disadvantages of introducing message-oriented middleware in system architecture?” Elaborate, please pay attention to.
END
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