Distributed architecture of websites

Internet websites use the B/S architecture model like most enterprise management software. However, the B/S architecture of large public websites is more complex and requires more architects, today, I want to talk about the B/S technical architecture of my website in my blog.

The Enterprise Management System of B/S architecture or website technical architecture can be abstracted as the following diagram:

In the traditional B/S architecture enterprise management system, the technical architecture is often a project, and each logic layer is the business logic module of the project. However, websites that provide public services have a large user base, high website concurrency, great demand changes, frequent changes, and security considerations for websites, the implementation of the above logic hierarchy in the technical architecture will be much more complicated. I recently made a website. The technical architecture I designed is illustrated below:

I split my website project into three subprojects: the front-end project, the server project, and the memcache project. The front-end project includes the page, static resources, and control layer. The server project includes the business layer and database operation layer; the memcache project caches data shared by front-end and server projects.

In system deployment, both the frontend project and the server project adopt a distributed approach (our website frontend is composed of four servers and the server is composed of four servers ), before a user requests enter, the Server Load balancer device is used to distribute requests. A firewall is deployed between the frontend and the server, and between the server and the database to ensure system security, front-end clusters and Server Clusters belong to different network environments. Front-end clusters can access the Internet, while the network of Server Clusters and databases cannot directly access the internet, however, the frontend network environment can communicate with the server network environment.

The server and client communicate with each other using custom packets. HTTP is used for transmission protocol. Because of the high security requirements of the website, the request protocol transmitted by users uses HTTPS.

To ensure the efficiency of communication between the server and the client, we use persistent connections for communication between the client and the server (the language of our website server is Java, and the communication layer is developed using the netty framework ), to ensure persistent connections, we have written a heartbeat detection service that runs in the background thread and detects the heartbeat every five minutes. Of course, the interval can be configured. In addition, we have estimated the maximum concurrency of the website in advance. When the website is started, we built a thread pool (the server we use is an 8-core processor, with a maximum thread count of 256 per core, therefore, the maximum number of threads in our thread pool is 8*256*4 = 8196). Each thread processes a user request.

Due to the distributed deployment of client projects, the session sharing problem exists. The session sharing mechanism of our website does not use the session sharing mechanism provided by the Web Container, but we have developed a session mechanism, the principle is very simple. Specifically, we will generate a unique identifier for each user session. Our unique identifier is designed as follows: the session ID of the current user + a random 16-digit combination of letters + the current nanosecond value, and then hash the value to calculate a key, the original values saved in the session are stored in the memcache cluster. The keys of the data are the unique identifier of the user. In the end, the front-end of our website does not use the session object, but the session mechanism we designed. We also encapsulate a set of custom tags to operate on our custom sessions on the page.

The server also has a similar sharing mechanism, but it is different. When the client requests the server, the request will be sent to a server on the server, because some requests of this website are asynchronous during processing, that is to say, some client requests are not returned to the user immediately, but are now distributed to the server. At this time, the client will return a user ID indicating that the request has been accepted and is being processed, A thread on the server has started to process the request. The client sends the request to the server at a certain interval to check whether the request has been processed. However, the server is also distributed and the request is randomly sent, client inquiries may be distributed to other servers. Therefore, for such requests, I will record the Server IP address and thread ID processed by the client, during the query, the system will access the specified server and thread until the request processing is complete, close the query, and return the result to the user.

As we split a website project into three independent projects, project management and coordination become more difficult. Therefore, we introduced the maven framework to manage and build the project, at the same time, a common project is built, which is responsible for the server and front-end publicProgramDevelopment.

This framework completely separates the presentation layer from the business processing layer. Therefore, the client engineer can concentrate on the client and the server engineer can concentrate on the server. You only need to learn how to encapsulate the communication protocol, therefore, it is conducive to horizontal expansion of project team members.

The above is the technical architecture I have designed for the company's website. I would like to share it with you. I hope you can give some constructive comments.