Distributed Systems
Why are we talking about microservices now? What problems did microservices solve? How does an application service evolve from a single machine to a cluster to the current microservice?
Through this article, it means that we are about to enter the distributed topic, this article is the pre-knowledge for the next distributed article
Distributed evolution
Monolithic Service
Introduction
Monolithic service is the simplest service. In the era of low traffic in the past, basically all services were monolithic services
The single service is roughly divided into 3 parts, 1 browser, 2 service, database. The user accesses the server through the browser, and the server will continue to operate the database according to the business and return the result to the browser.
There is a problem with the monolithic architecture
- Based on JVM internal calls, they are all calls in a process
- There will be a single point of failure after browsing and concurrency
Cluster service
Introduction
When the concurrency and traffic are getting higher and higher, the monolithic architecture will not be able to withstand the pressure, and then there will be new solutions, clusters
Clustering is to deploy exactly the same application on two servers, and then use nginx to do load balancing, and evenly distribute client services to two different servers for processing
There is a problem with the cluster service
Session sharing issues
That is, the user connected to server 1 after logging in for the first time. After a period of time, because the load of server 1 is full, when the user accesses the request again, Nginx distributes the request to server 2, because servers 1 and 2 are completely isolated So, after the user request is distributed to server 2, server 2 will think that the user is not logged in and needs to log in again
Session sharing problem solution
- Session Stick
Session Stick uses Nginx's algorithm IP_Hash. When a browser serves Nginx, Nginx can obtain the IP address of the accessed browser and use the Hash algorithm to obtain the corresponding Hash value, and then specify the Hash value to always access the same one server
Problem 1: Because not every client has its own IP address, for example, a company accesses only one network cable from the operator and then builds the company’s internal LAN through this network cable to distribute to employees’ computers, but employees access In the end, the web pages actually use the same Internet to access the same network cable, so when Nginx calculates the Hash, the same one will always be distributed to one service, which will cause the problem of unbalanced load.
There is a problem two: because the designated server access is calculated through Hash, if the accessed service goes down, Ngxin does not know it at all. There will be a problem in this city, but after the service goes down, the user will be distributed to a downtime. Is not accessible on the service
- Session Relication
Session Relication is to configure Tomcat to use the characteristics of TCP/IP. When a user connects to a service, the server will notify the user's session to other servers, so that other servers will save the user's session and Know that this user is logged in
Problem 1: If there are currently 10 service clusters, when a user connects to the service, the server needs to notify the session that the current user is successfully connected to the other 9 servers. Because of the use of TCP/IP, part of it will be occupied. Bandwidth affects server performance
Problem 2: When the number of clusters is large, mutual backup of sessions will be a problem of session redundancy, because after the servers notify each other of the sessions, each server saves a complete list of sessions
- Cookie Base
Cookie Base encrypts the authenticated session data after the user logs in successfully, and saves it in the cookie of the browser, but when the user accesses the service, it will authenticate the session data in the user cookie for authentication. A typical example Token is based on Cookie Base.
Problem 1: Since the Session data is stored in the client, the client can forge someone else's Session to access the service
The second problem: Since the session data is stored in the client, the session is more likely to be stolen by other criminals
- Session Center
Session Center will store the session data in Redis (a memory database with fast read and write speed) after the user logs in successfully. When the user accesses, the server will go to Redis to obtain the validity of the current user's Session verification. This method is also The most extensive and safe method available
Database IO pressure problem
The addition of servers eases the concurrency of user access, but the database is always a stand-alone version. Finally, as the user access traffic increases, the database IO pressure gradually increases, and eventually the entire architecture will still have a concurrency bottleneck
Database IO pressure problem solution
- Read and write separation, master-slave synchronization
Read-write separation is the deployment of multiple databases. Due to the particularity of Internet applications, the read-write separation is composed of a master library and multiple slave libraries. The master library is mainly responsible for addition, deletion and modification operations, and the slave library is mainly responsible for query operations. All data operations in the main library will be synchronized to the slave library in real time to ensure that the data in the slave library is consistent with the data in the main library
There are 2 ways to read and write separation (proxy and jdbc)
proxy：mycat、altas、mysql-proxy
jdbc：tddl、sharding-jdbc
- Sub-library and sub-table
Read-write separation cannot solve the problem of slow time-consuming query and insertion of large tables. Read-write separation is only a transitional solution. If you want to truly obtain the most powerful database, then you must combine read-write separation with database and table splitting. In the coming days, one database will be split into multiple and data tables will be split. If a database needs to withstand access pressure of 10W, then we will split it into 10 databases. In theory, the pressure of each database has dropped to 1W.
There are 2 ways to sub-database and sub-table (proxy and jdbc)
proxy：mycat、altas、mysql-proxy
jdbc：tddl、sharding-jdbc
- Change the database, there is nothing to say about this, just change the Oracle database if you have money
Servicing
Why serve
When the system involves more and more businesses and more and more functions, if it is still a single application, there will be some problems when it is released and online. For example, the current e-commerce project is divided into two departments and the commodity department currently needs new functions, The conference department fixes known bugs, but after the two departments have completed the tasks and passed the test, they are deployed and launched. After the launch, it is found that there are problems with the new functions of the commodity department. Then the release of this version is a success or a failure. According to the current situation, it should be a commodity The department failed to go online, and the conference department went online successfully, but because the current project is a whole, the functions of rolling back products and members online must be rolled back at the same time
Servicing
For the problems that exist during the above deployment, the solution is to serve the entire application and split the functions into modules. If there is a problem with the commodity service when it is launched, then only the commodity service needs to be rolled back, and if the order center is in the running process of the application Downtime, it will not affect the normal use of other services
Since the entire framework is layered, if the application layer needs to call the atomic layer method, there will be a remote procedure call (RPC)
RPC框架：dubbo、spring could
