high performance architecture

Overview

Performance includes a variety of dimensions to consider. The most intuitive are two indicators: single request time and throughput
. A single request time directly affects the user experience, that is, whether the web page opens quickly or not. Throughput reflects the concurrency capability of the system.
To improve the performance of the system, the synergy of each link of the system is required.
Front-end high performance

Front architecture optimization can often intuitively shorten the single request time. In addition, it is also valuable for improving system throughput. For example, if it is well designed, the front-end will bring less pressure to the back-end, which indirectly improves the concurrent response capability of the system.
CDN
CDN is an artifact of front-end performance. For the same architecture, there is a big difference in performance whether a CDN is used.
To use a CDN, the application architecture must first be separated from static and dynamic. If it is a back-end rendering page, then the dynamic page basically has to go back to the source every time, and the CDN will be lost. Meaningful
In addition if static resources and service interfaces are deployed under different domain names, there may be cross-domain problems on some mobile browsers. Therefore, you can consider deploying the html and the interface under the same domain name, filtering out the cache of dynamic requests with the path, returning directly to the source,
compressing files, and reducing the amount of network transmission.
Deploying the development css and javascript directly to the production environment will increase the transmission of http requests Therefore, this part of the resource needs to be compressed. You can use gulp or grunt to simplify
merging requests and reduce the number of network requests.
Similarly, merging javascript and css to reduce the number of requests will also improve front-end performance
. Optimize the writing method of html itself
. There are many detailed issues here, so I won’t go into details. . For example, scripts should be written at the end to prevent scripts from blocking page loading and rendering, and to improve the efficiency of DOM operations, etc.
Other more powerful technologies
Such as facebook's BigPipe and so on. There are also some companies in the industry that are using it. I have only heard cases shared by others. I can understand the principle but have not practiced it.
Application layer high performance

Compared with the data layer, it is relatively simple to improve performance in the application layer. One of the core principles is to keep the server stateless, because it is easy to scale horizontally, and use the cluster to improve the load capacity of the system.
Cluster + load balancing
This is the most common practice. Basically, as long as the server is stateless, it will not be too difficult to build a cluster with horizontal scaling.
In order to achieve stateless services, it is usually necessary to externalize various local dependencies, such as sessions, locally stored files, etc., which need to be implemented from the service itself. It is easy to
build a cluster, but the difficulty is engineering, which can achieve rapid on-demand scaling and improve the availability of the cluster. This is a more complex topic.
Distributed + asynchronous message queue
When the system grows to a certain scale, it will generally It is split into smaller distributed systems. Then, through asynchronous queues, the business logic is divided into small-grained units, so that each request becomes multiple lightweight requests, and then connected in series through asynchronous messages to cut peaks and reduce resource competition on a single machine.
In fact , using a distributed architecture, not just for performance reasons. Proper splitting is encouraged even when the system is relatively small. In addition to performance considerations, distributed systems have other benefits.
For example each group can maintain a smaller system, which is beneficial to development; from the perspective of operation and maintenance, each subsystem can be started and stopped independently, and edge services can be The failure will not affect the main process; it is also conducive to service reuse. For example, if the underlying basic account subsystem is independent, the upper-level business module does not need to repeatedly write account-related code.
Cache
Needless to say, cache is also an artifact of system performance. Cached data is essentially in memory, and its speed and concurrency far exceed hard disk IO. A high concurrency system is unimaginable without a cache
In terms of architecture, it is self-evident to use the cache. The main thing to consider is how to improve the hit rate of the cache and improve the availability of the cache.
Data layer high performance

Data layer, especially relational database, it is more troublesome to achieve high performance
Because database is essentially a stand-alone system, it is naturally stateful (data is its state), so it is difficult to scale horizontally as easily as an application server.
On the other hand, when a single database is saturated, it is also very troublesome to split the database, because This split is often not transparent to the application layer, and requires additional processing by the application layer. For example, database routing, cross-database join, cross-database transactions, etc., are more complicated than single-database. Many
SSDs
have a saying that "the most powerful optimization is to buy SSD"
indexes.
For large tables that are frequently read and frequently joined, a suitable After the index, the performance improvement is very sour. Read-
write separation
The main database is responsible for reading and writing, and the slave database is read-only, which is also a conventional method.
Sub- database and sub-table
When a single database or single expression reaches the upper limit of capacity, it is necessary to consider splitting , there are vertical splits and horizontal splits when splitting.
Vertical splitting is to split tables into different libraries according to business relevance. The main problem to be solved is the IO competition between tables and tables.
Horizontal splitting is to split a single table into multiple tables. It does not solve the IO competition between tables and tables, but it can solve the problem of excessive single table capacity.
For example, a library Originally there were 2 tables, users and orders. Put the user table in db1 and the order table in db2, this is vertical split. Divide the order table into two, which is divided into the completed order table and the unfinished order table, which is the horizontal split.
Obviously , the sub-database sub-table is a
NOSQL that needs to be perceived by the application layer
You can consider putting unstructured data into nosql, such as mongodb, etc. The disadvantage is that it sacrifices some features of traditional relational databases, mainly transaction and join capabilities. But usually the query efficiency and capacity of nosql database are more than that of relational database
<script type="text/javascript"> $(function () { $('pre.prettyprint code').each(function () { var lines = $(this).text().split('\n').length; var $numbering = $('<ul/>').addClass('pre-numbering').hide(); $(this) .addClass('has-numbering').parent().append($numbering); for (i = 1; i <= lines; i++) { $numbering.append($('<li/>').text (i)); }; $numbering.fadeIn(1700); }); }); </script>