Hello everyone, today I would like to introduce to you a very hot technology, and also a topic that interviewers like to ask during the interview, that is the underlying principle of SpringCloudAlibaba.

Now as we all know, SpringCloudAlibaba is popular in Java development industry, all companies are using this technology, so we Java engineers go out for interviews, interviewers have made SpringCloudAlibaba interview options, every interview, there will always be interviewers ask: “Bro, did SpringCloudAlibaba play? Can you talk about the underlying principles of SpringCloudAlibaba?”

At this point, if you look confused and say: “Brother, we are playing SpringCloud, why do you add Alibaba? Since when does this have anything to do with Ali?” Congratulations, the interviewer will probably excuse yourself for a stomachache and call it a day in 30 minutes.

Therefore, this article is to hope that you brothers do not appear above the kind of 30 minutes forced to end the interview embarrassing questions. Today, we first step by step to let you understand what technology components are included in SpringCloudAlibaba, what are used in the system, and then to analyze the underlying principles of these technologies.

First of all, suppose you have two systems in your company, let’s say system A and system B. The current requirement of these two systems is that System A can send A request to system B to implement the interface call between the systems. Let’s look at the figure below.

The biggest question is, if system A is deployed on one server and System B is deployed on another, how can system A somehow know which machine SYSTEM B is deployed on? This is like saying, you are walking on the street, see a beauty, home especially want to contact her wechat, the results you do not know her micro signal, did not add friends, without a thin air can not chat with beauty ah!

So what’s the right way to approach a beautiful woman? This has to have a premise, is that you have a friend in the middle, he knows the beauty of someone else’s micro signal, this time you can find the friends in the middle to someone else’s micro signal, and then add someone else’s beauty friends according to the micro signal, and then you can achieve seamless emotional communication!

Just kidding, this is just an interlude in A boring technical article, but for your system A, this is the time to introduce A key technology component of SpringCloudAlibaba called Nacos. Keep your eyes peeled. Nacos is a key term to keep in mind. Its academic orientation is called “service registry.”

This Nacos is similar to the third party friend who has the beautiful girl’s wechat account mentioned above. He knows which machine your system B is deployed on, because system B will take the initiative to register the service with the Nacos service registry when it is started, and tell Nacos that it is deployed on which machine. The IP address of the host is 172.86.76.251 and the port number is 20880.

At this point, system A, if it wants to call system B’s interface, can send A request to the Nacos service registry saying, brother, can you tell me which machine System B is deployed on? I want to invoke his interface, which is technically called “service discovery.”

Then, the Nacos service registry will be generous enough to tell you system B’s wechat id, oh no, system B’s machine IP and port number. At this point, system A knows the IP address and port number of system B, and can send A request to call the interface of system B, as shown in the figure below.

Let’s look at the next question, suppose system B is A big beauty, and then there are more than one twin sisters flower, that is to say system B deployed in multiple servers, we call this kind of circumstance system B have more than one service instance deployed on multiple servers, and then the system want to invoke A B, what should I do? Let’s look at the picture below.

After each service instance of System B deplores a machine, they have to make a service registration request to the Nacos service registry, so Nacos knows the IP address and port number of each machine deployed in system B, as shown in the figure below.

When system A seeks Nacos for service discovery, it will immediately discover that System B is deployed on two machines, that is, the IP address and port number of both machines will be discovered. Now, the problem is, system A is hesitant, which machine is calling system B?

Very simply, he can call machine 1 the first time, machine 2 the second time, machine 1 the third time, machine 2 the fourth time, and so on. This process is called load balancing. System A can distribute all its requests evenly to each machine in system B by load balancing.

Then the next question comes again, the system if you want to call system approach to B an interface, it must be with system B to set up A network connection, and then through the network connection sends A request to system B in the past, then system B has received the request, then will call himself an interface of the local code, The response is then sent back to system A over the network connection. This process is called an RPC remote call, as shown in the figure below.

In fact, this RPC call process is similar to the process of chatting with people on wechat. You have to add a friend in wechat chat first, and then send a message to the other person, and then the other person will reply to you, right? Yes, this RPC call is the same, you two machines have to establish A network connection, and then system A sends A request to the past, system B local code executes, and then return A response to you.

System A has to load balance multiple machines deployed by System B, establish A network connection, and then initiate an RPC call. System A sends A request, and System B executes A code and returns A response. Who is responsible for this seemingly complicated process?

Simple, Dubbo is another key component in SpringCloudAlibaba

Dubbo is an RPC framework that helps you with load balancing, network connectivity, and RPC calls. This is the second key component in SpringCloudAlibaba’s component architecture, as you can see below.

Moving on to the next question, which many of you may or may not know, is this: How many concurrent requests per second can a 4-core 8-GIGAByte server handle?

If it is a Java system, and the Java system is connected to the mySQL database, then generally speaking, the server can resist less than 1000 QPS per second, as shown in the following figure. 1,000 requests per second and I’ve highlighted it in red.

Why is that? The reason is very simple, we need to analyze from two dimensions, the first dimension is how many threads of our system A to process requests, how many ms to complete each request, how many requests each thread can execute per second;

The second dimension is how much pressure will be placed on the CPU load of the machine when the N threads of system A desperately process requests. The CPU of the machine will be overwhelmed when all the threads process requests per second.

Once you’ve solved these two problems, you’ll know how many requests your system can handle per second.

Let’s start with the first dimension. Generally speaking, system A receives external requests from users through A Web server like Tomcat. Spring MVC provides interface like Controller, and receives HTTP requests. This means that system A has 200 threads concurrently processing requests from users, as shown in the figure below.

So the next question is: How long does it take the Tomcat thread to process a request?

If you use Mybatis as the data persistence layer framework, then you should use MyBatis Mapper to execute a lot of SQL statements. This often depends on how complex your system code is, how complex the SQL statements you execute, how many SQL you execute, whether the tables in your database are ten thousand, one hundred thousand, one million, or even ten million or ten million.

Therefore, there are too many influencing factors, so we take an average value of no more than no less. Assuming that you need to call the database for N times and execute N SQL statements for a request, and the amount of data in the database is still small, ranging from 100,000 to millions, it will cost about 200ms to process a request, as shown in the figure below.

So a simple elementary school formula can be worked out. If you have a thread processing a request for 200ms, you can process 5 requests per second. If you have 200 threads, you can process 200*5=1000 requests per second.

So, in this dimension, it makes sense for system A to deploy on A 4-core, 8GB system, connect to the mySQL database, and then open 200 Tomcat threads to process requests at 1000 requests per second.

What about the second dimension? CPU load is the point of view, is also the same, this can not count can be used to calculate, can only tell you one experience value, that is when your system deployment in 4 nuclear 8 g machine, connect the mySQL database, and then each request to perform a heap of SQL statements, often, your system processing to around 1000 requests per second, Your machine will be running at 80 or even 90 percent of its CPU capacity, which is already too high to handle any more requests.

Ok, so in terms of the experience value that system A can handle 1,000 requests per second, let’s consider A question. What if your company has an activity and suddenly 2,000 requests come in every second, or is attacked by A hacker, and the number of requests per second is very high? Obviously your system A will be killed, as shown below.

So what do you do at this point? We have to introduce the third component in SpringCloudAlibaba, which is Sentinel, which is to help your system implement traffic protection.

When you add Sentinel to system A, if you get more than 1,000 requests per second, Sentinel will reject those extra requests for you. This is called flow limiting, limiting the number of requests your system can handle and protecting your system from being killed, as shown below.

Nacos is the service registry, Dubbo is the RPC call framework, Sentinel is the traffic protection component, and then the last component is Seata, the distributed transaction component.

Since the mention of distributed transaction, it is certainly with transaction is related to, this transaction I believe we all know, is that we can open a transaction for mySQL, transaction execution n SQL, whenever there is a SQL failed, transaction will be rolled back, the N SQL will not take effect.

But what about transactions in A distributed scenario where system A calls system B? System A executes A bunch of SQL on its own database and commits transaction A. System B then invokes an RPC call to system B via Dubbo. System B executes A bunch of SQL on its own database and commits transaction B.

Transaction A of system A is committed, and transaction B fails to execute when system B rolls back. That is to say, a request was processed inconsistently, a successful transaction on one system was completed and cannot be rolled back, and a transaction on another system failed!

Don’t worry, this problem can be easily solved by introducing the Seata distributed transaction framework, which automatically records the reverse compensation SQL of the SQL statements executed by your transaction A. What does that mean? If you perform an INSERT in transaction A, then Seata knows that it can delete the data during compensation. If you perform an update, Then Seata can record the data before the update. When compensating, It can update the data back to the old version. The reverse compensation log is also recorded in the database, as shown below.

Seata also provides A Seata Server to monitor the transaction execution of your systems. System A informs Seata Server of the successful transaction execution of system A, and system B informs Seata Server of the failed transaction execution of system B, as shown below.

When Seata server know your transaction system B B failed to perform, he will tell the system A Seata in framework, little brother, the family system B fails, you get to the, don’t ink, put your records before the transaction log out A reverse compensation, transaction recovery of before you submit to submit the data before the state, make A reverse rolled back, The diagram below.

Ok, so far, we will introduce the usage scenarios and working principles of several components of SpringCloudAlibaba component system, including Nacos service registry, Dubbo RPC call framework, Sentinel traffic protection component, Seata distributed transaction component, Look at the picture above, isn’t it a sense of achievement? Please keep this in your collection and show the above picture to the interviewer during the interview. If you know what you are doing, the interview process will continue smoothly.

END
[Architecture Notes of Ishiki] Reader exchange group (for technical dry goods, technology sharing, workplace communication), scan code reply:666, join now:

If you want to learn more about the actual practice of Spring Cloud Alibaba in large-scale projects, I recommend the large-scale Enterprise-level Distributed Order System Project produced by Ruape Classroom. For details of the course, please refer to sourl.cn/aict6k