Shulou(Shulou.com)06/03 Report--

Today, the editor will bring you an article that introduces the characteristics of the changes in the software architecture phase, as well as the reasons and relationships before and after the architecture replacement. The editor thinks it is very practical, so I will share it for you as a reference. Let's follow the editor and have a look.

The Evolution of Architectural Design

The development of business-driven technology is immutable. At the beginning, the volume of business is small, the business complexity is low, and the technology adopted is relatively simple, which basically meets the functional needs of users. With the popularization of IT information, more and more transactions are put on the network, the increase of information and frequent visits are the problems to be solved. Therefore, caching, clustering and other technical means are gradually added. At the same time, the requirements for scalability and scalability of the business are getting higher and higher. High concurrency, high availability, scalable, scalable and secure software architecture has always been the goal of architecture design. Today we take a look at what stages the architecture design has gone through, what problems have been solved in each phase, and what new problems have emerged. The main purpose is to arouse everyone's thinking. It is the goal of IT people to adopt appropriate technical means at different stages of business development and embrace change with change.

Integrated application and data model

The earliest business applications are mainly websites, OA, etc., the number of visitors is limited, a single server can cope with. Typically, the application and database are deployed to a server, as shown in figure 1-1. At this stage, we can do it quickly using LAMP (Linux Apache MySQL PHP) technology, and these tools are open source. For a long time, a variety of open source code for this application model has been available. This model basically does not require high concurrency and has poor availability. Some servers adopt the hosting mode, and different business applications are installed on it. Once there is a problem with the server, all the applications will go on strike. However, its development and deployment costs are relatively low, so it is suitable for fledgling application services. Figure 1 depicts the pattern of a single application and database running on a single server, which we call the integrated application and data pattern.

Figure 1 Integrated application and data model

Application and data separation mode

With the development of business, the number of users and requests are gradually increasing, and there are problems with the performance of the server. A relatively simple solution is to increase resources to separate business applications from data storage, and the architecture diagram is shown in figure 2. Among them, the application server needs to deal with a large number of business requests and has certain requirements for CPU and memory, while the database server needs IO operations such as data storage and indexing, and more consideration will be given to disk speed and memory. This separation solves the performance problem, and we need to expand more hardware resources to make them perform their respective duties, so that the system can handle more user requests. Although there is still business coupling, hardware-level separation is much better in usability than integrated design.

Figure 2 Application and data separation mode

The addition of cache

With the development of information system and the increase of the number of people using the Internet, the volume of business, users and data are all increasing. We also find that users have a particularly large number of requests for certain data, such as news, commodity information and hot news. Previously, the way to obtain this information is dependent on the database, so it is affected by the performance of the database IO. At this time, the database has become the bottleneck of the whole system. If you increase the number of servers, it will be difficult to solve, so caching technology comes out, and its architecture diagram is shown in figure 3. The caching technology mentioned here is divided into client browser cache, application server local cache and cache server cache.

Client browser cache: when a user requests a server through a browser, a HTTP request is initiated. If you cache each HTTP request, you can reduce the pressure on the application server. Application server local cache: it uses in-process cache, also known as managed heap cache. Take Java as an example, this part is cached on the managed heap of JVM and is affected by the managed heap recovery algorithm. Because it runs in memory and responds quickly to data, we usually put hot data here. When the in-process cache misses, it will go to the cache server to get the information, and if it still fails, it will go to the database to get the information. Cache server cache: compared to the application server local cache, it is the out-of-process cache, which can be deployed either on the same server as the application service or to different servers. In general, in order to facilitate the management and rational use of resources, it will be deployed to a dedicated cache server. Because caching takes up memory space, such servers configure a larger amount of memory.

Figure 3 depicts the order of cache requests, first accessing the client cache, then the local cache within the process, then the cache server, and finally the data. If the cache information is obtained at any layer, there is no further access, otherwise the cache information will be obtained in this order all the way to the database.

Fig. 3 addition of cache

The order in which users request access to data is the client browser cache → application server local cache → cache server cache. If the data has not been hit in the above order, the database will be accessed to obtain the data.

The design of adding cache improves the performance of the system. Because it is cached in memory, and the reading speed of memory is much faster than that of disk, it can respond to user requests quickly. Especially for some hot data, the advantage is particularly obvious. At the same time, there is also a significant improvement in usability. Even if the database server fails for a short time, the hot spots or core data saved in the cache server can still satisfy the user's temporary access. Of course, usability will be optimized later. Join the server cluster

After the evolution of the first three stages, the system has a good support for the number of users' requests. In fact, this is to solve the problem of high performance and availability, and this core issue will continue to run through the evolution of the entire system architecture. With the increase in the number of user requests, another problem arises, which is concurrency. Take the two words apart: and, understand it as "parallel together", which means at the same time; send, understand as "make a call", that is, the meaning of request. Together, multiple users request the application server at the same time. If the original system only faced with a large amount of data, then now it needs to face multi-user requests at the same time. If it is deduced according to the architecture diagram of the previous phase, a single application server can no longer meet the requirements of high concurrency. At this point, the server cluster joins the battlefield, and its architecture diagram is shown in figure 4. Server cluster means that multiple servers are clustered together, using more servers to share the load of a single server to improve performance and availability. To put it more bluntly, it is to increase the number of requests processed by the service per unit time. It used to be handled by one server, but now it is handled by a bunch of servers. Just like the bank counter, increase the number of tellers to serve more people.

Figure 4 joining the server cluster

Compared with the last time, this architecture evolution increases the number of application servers and uses multiple application servers to form clusters. The application service deployed in the application server remains unchanged, and a load balancer is added between the user request and the server to help the user request route to the corresponding server. The move to increase the number of servers shows that the bottleneck of the system is in handling concurrent requests from users. No changes have been made to the database and cache, so the pressure on the request can be relieved simply by increasing the number of servers. The server cluster will share the requests that the original server needs to process through multiple servers, and run a system on multiple servers at the same time, so it can handle a large number of concurrent user requests at the same time. It is a bit like three cobblers to be called Zhuge Liang, so the hardware requirements for a single server in the cluster will also be reduced. At this point, we need to pay attention to the algorithms of load balancing, such as polling and weighted polling. We want to ensure that user requests can be evenly distributed to the server, requests for the same session are guaranteed to be processed on the same server, and traffic is dynamically adjusted according to the advantages and disadvantages of different server resources. After the load balancer is added, because it is located between the Internet and the application server, it is responsible for the access of user traffic, so it can monitor user traffic and verify the identity and permissions of access users.

Database read-write separation

Adding cache can solve the problem of reading some hot data, but the capacity of cached data is limited, and those non-hot data will still be read from the database. The performance of the database is different for writes and reads. When writing data, it will cause rows or tables to be locked, and if other write operations are executed concurrently, there will be a queuing phenomenon. The read operation is faster than the write operation, and can be realized by indexing, database caching and so on. Therefore, a scheme of database read-write separation is proposed, and its architecture diagram is shown in figure 5. At this time, the master-slave database is set up, and the master database (master) is mainly used to write data, and then the updated data is synchronized to the slave database (slave) by synchronizing the binlog. For the application server, you only need to access the master library when writing data and only access the slave library when reading the data.

Fig. 5 Separation of database read and write

The read / write responsibility of the database is separated by the way of database read / write separation. Take advantage of the high efficiency of reading data, expand more slave libraries, so as to serve the user requests of the read operation. After all, in a real-world scenario, most operations are read operations. In addition, from the perspective of data synchronization technology, it can be divided into synchronous replication technology, asynchronous replication technology and semi-synchronous replication technology. While the separation of database reads and writes brings benefits, the architecture also needs to consider the issue of reliability. For example, if the master library dies, how does the slave library take over the work of the master library. After the recovery, whether the master library will become the slave library or continue to act as the master library, and how to synchronize the data.

Reverse proxy and CDN

With the gradual popularization of the Internet, people have higher and higher requirements for network security and user experience. In the past, users used to access the application server directly through the client to obtain services, and the application server will be exposed to the Internet and vulnerable to *. If a reverse proxy server is added between the application server and the Internet, it receives the user's request, and then forwards it to the application server of the intranet, acting as a buffer between the extranet and the intranet. The reverse proxy server only forwards requests and does not run any applications on it, so when someone has sex with it, it will not affect the application server of the intranet. This virtually protects the application server and improves security. At the same time, it also plays a role in adaptation and speed conversion between the Internet and the intranet. For example, the application server needs to serve the public network and the education network, but the network speeds of the two networks are different. You can put two reverse proxy servers between the application server and the Internet, one to connect to the public network and the other to connect to the education network to shield network differences and serve more user groups. As shown in figure 6, the public network client and the campus network client come from two different networks: the public network and the campus network. Because the two networks have different access speeds, a common network proxy server and a campus network proxy server will be set up for the two networks respectively. In this way, the users located in the impassable network will request access to the system.

Figure 6 adding a reverse proxy server

After talking about reverse proxy, let's talk about CDN, its full name is Content Delivery Network, that is, content delivery network. If you think of the Internet as a large network, each server or client is a node distributed in the network. The distance between the nodes is far and near, and the user request will jump from one node to another, and finally jump to the application server to obtain information. The fewer times you jump, the faster you can get the information, so you can store the information in the node close to the client. In this way, the user can access the information through the client with less jump times. As this part of the information is not updated frequently, it is recommended to store some static data, such as JavaScript files, static HTML, picture files and so on. In this way, the client can obtain resources from the nearest network node, which greatly improves the user experience and transmission efficiency. The architecture diagram after joining CDN is shown in figure 7.

Figure 7 join CDN

The entry of CDN not only accelerates the speed of users' access to the application server, but also reduces the pressure on the application server. It is necessary to directly access the request of the application server, without going through layers of networks, but only to find the nearest network node to obtain resources. However, from the point of view of requesting resources, this method also has limitations. It can only work on static resources and needs to update the resources of the CDN server regularly. The addition of reverse proxy and CDN solves the problems of security, availability and high performance.

Distributed database and sub-table and sub-database

After the previous stages, the system architecture of the software tends to be relatively stable. With the increase of the running time of the system, more and more data are accumulated in the database. At the same time, the system will record some process data, such as operation data and log data, which will also increase the burden on the database. Even if the database is indexed and cached, it will be stretched when querying large amounts of data. If the separation of read and write is to allocate resources from the read-write level of the database, then the distributed database needs to allocate resources from the business and data level.

For a data table, when the table contains too many records, it is divided into multiple tables to store. For example, if you have 10 million membership records, you can divide them into two 5 million and store them in two tables. The columns in the table can also be divided according to the business, some columns in the table can be stored in other tables, and then associated to the main table through foreign keys, and the split columns are usually infrequently accessed data. For a database, there is an upper limit on the maximum number of connections and connection pooling that each database can withstand. In order to improve the efficiency of data access, the database will be segmented according to business requirements, so that different businesses can access different databases. Of course, different data from the same business can also be stored in different libraries.

If these database resources are put into different database servers, it is a distributed database design. Because the data is stored in different tables / libraries, even on different servers, it will increase the complexity of the code when performing database operations. At this point, database middleware can be added to eliminate these differences. The architecture is shown in figure 8, the data is split and placed in Table 1 and Table 2 respectively, the database servers of the two tables are also different, and the problem of data synchronization needs to be considered between libraries. Due to the decentralized deployment of data, it is necessary to rely on database middleware to obtain data from business applications.

Fig. 8 distributed database and sub-table and sub-library

The sub-table and distributed design of the database will not only improve the performance, but also increase the difficulty of database management and access. Instead of accessing only one table and one library, you now need to span multiple tables and libraries.

From a software programming perspective, some database middleware, such as MyCat and Sharding JDBC, provide best practices. In addition, from the perspective of database server management, you need to monitor the availability of the server. From the point of view of data governance, the problems of data expansion and data governance need to be considered. Business split

When the problem of large amount of data storage is solved, the system will be able to store more data, which means that it can handle more business. The increase of business volume and the increase of visits is a severe test that any software system has to face at any time. Through the previous stages of learning, we know that the improvement of the system basically depends on space for time, using more resources and space to deal with more user requests. With the increasing complexity of the business and the advent of high concurrency, some large factories begin to split up the business systems and deploy them separately. The architecture diagram at this time is shown in figure 10. If the previous server cluster mode is to copy the same application to different servers, then business split is to split an application into multiple deployments to different servers. In addition, core applications can be scaled horizontally and deployed to multiple servers. Although the applications have been split, there are still connections between applications, and there are problems of calling, communication and coordination between applications. As a result, middleware such as queues, service registration discovery and message centers will also be introduced, which can help the system manage applications distributed to different servers and network nodes.

Figure 9 Business split

After the business split, application services will be formed one by one, including business-based services, such as merchandise services, order services, and basic services, such as message push and permission verification. These application services and database servers are distributed in different containers, servers and network nodes, and the communication, coordination, management and monitoring of them are all problems that we need to solve.

Distributed and micro services

In recent years, micro-service is a more popular way of architecture, which cuts business applications more finely, making them smaller business modules. To achieve high cohesion and low coupling of modules, each module can exist independently and maintained by an independent team. Unique technology can be adopted within each module without paying attention to the technical implementation of other modules. The module runs through the deployment of the container, and the modules are called through interfaces and protocols. Any module can expose itself to other module calls. At the same time, the hotspot module can be expanded horizontally to enhance the performance of the system. When there is a problem with one of the modules, it can be replaced by other identical modules to enhance the usability.

To sum up, microservices have the following characteristics, such as fine business separation, autonomy, technological heterogeneity, high performance and high availability. It looks a lot like a distributed architecture, so let's take a look at the differences, as shown in figure 10.

Conceptually, they all do the action of "dismantling", but there are differences in the following aspects.

The purpose of splitting is different: distributed design is to solve the problem of limited resources of a single application, which cannot support higher user access on one server, so break up an application into different parts and deploy it to different servers to share the pressure of high concurrency. Micro-service is to refine the service components, the purpose is to better decouple, so that through the composition of services to achieve high performance, high availability, scalability and scalability. The split method is different: the distributed service architecture splits the system according to business and technology classification, in order to load the split service with the business of the original single service. Microservices are split more finely on a distributed basis, which divides the services into smaller modules, more specialized, finer division of labor, and each small module can run independently. Deployment is different: after the service is split in a distributed way, it is usually deployed to different servers. The micro-service can also put different service modules on different servers, at the same time, it can also deploy multiple micro-services on one server, or multiple backups of the same micro-service, and deploy in the way of containers.

Figure 10 the difference between distributed and micro-services

Although there are these differences between distributed and micro-services, from a practical point of view, they are all based on the idea of distributed architecture. Micro-service is a distributed evolutionary version and a subset of distributed services. It will also encounter some problems, such as service split, service communication, coordination, management scheduling and so on. This is the end of the evolution of software architecture. I hope the above content can be helpful to you and learn more knowledge. If you like this article, you might as well share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.