Background Development Technology (2)--Access layer design

Usually the server directly connected to the client is called the Access server, and one or more access servers constitute the access layer. The access layer has the following functions:

1. Maintains network connectivity to clients and manages network status for clients.
2. Receives a client request, forwards the request to the business layer, and forwards the data sent by the business layer to the client.
3. Access to the nearest, load-balanced, optimized network experience.

It can be found here, if the access layer with the business layer can also achieve the above functions, and save the implementation of the function 2 required workload, according to the principle of simplicity, the access layer should not be independent. For a single function, fewer users, concurrent small system, the access layer does not have to be independent. But for a complex system, merging the access layer and the business layer inevitably leads to a complex code code for a business module, as shown in:

This is part of an e-commerce system architecture that incorporates the access layer in the user module. In general, the backend system has a simple to complex evolution process, in the process will go through multiple version iterations, each time there will be development-test-release on-line, each release will restart the server. Take the user module, the first version is generally very simple, only the user registration, login, query user information of the functions, in order to improve conversion rate, will quickly accelerate the non-registered users shopping and shopping process, you need to use the module to increase the ability to manage temporary users. As the user volume increases, the user module needs to be designed to be distributed. In this way, the user module needs to be restarted due to the release of the launch, the restart will be due to the user experience, more serious is that if the user is doing money-related operations such as payment, it is likely to cause direct economic losses. Similarly, the function iterations of the access layer are also affected by the new user registration and the old user login. If the access layer is independent, it can effectively reduce the failure.

The simpler the function, the less change the server, the easier it is to be stable. Compared to the business layer module, the Access server function is relatively simple and very few changes. In other words, access servers are easier to stabilize than business layer modules. The access server is directly connected to the user, and it directly affects the user experience. An Access server failure or a restart will certainly affect the user, while other business module failures or reboots do not necessarily affect the user experience. From this point, we should try to avoid the adverse effects of other modules on the access server.

The benefits of the access layer being independent are:

1. Reduce the access layer and business coupling degree, reduce the stability of the module to the high stability of the module adverse effects.
2. Enable the business layer to focus on business processing and reduce the complexity of business layer design.
3. The access layer focuses on message forwarding, which can effectively reduce the loss rate of messages and improve the stability of the system.
4. The access layer significantly increases the user access experience at a small cost.

The ultimate goal of architecture design is to meet business requirements, and access layer design is no exception. There are a few things you need to know when designing the access layer: what are the requirements for network latency? How big is the concurrency? But what is the average length of the message? What is the user size? What is the geographical distribution of users? What is the user's network environment? Having a clear understanding of these issues will enable you to design the right access layer architecture.

The architecture of the access layer is that as the number of users increases, traffic increases, access concurrency increases from simple to complex evolution, as shown in

1. Single IP address access

2. Multiple IP address random access

3. DNS returns the Access address based on the user location and the user's network operator

4. DNS Returns a level two boot server address based on the user location and network operator, and the two-level boot server returns the access address based on load conditions and business requirements

Of the above four architectures, the 1th can be set up with an open source DNS server bind. The 2,3,4 architecture needs to develop a DNS server itself, the key is the need for an IP library, which records the different IP address segments belong to the geographic region and operators.

Client state Management

The status of the management client is another main remorse of the access layer, when the client connects to the access server, the connection will have a different status, such as visitor status, login status, etc. For different types of connections, the management status of the hair method is not the same. In general, there can be two different types of connections between a client and a server:

1. Long connection. With the TCP protocol, the TCP connection needs to be kept as close as possible after it is established, and is connected through the heartbeat to achieve reconnection. Typically used in scenarios where the client needs to passively accept data.

2. End connection. TCP,UDP, a request--is returned as a data exchange, and if TCP is disconnected after completion.

Message recognition

To manage client status, the first step must be to identify the client message. If there is a A, a, two clients connected to the server, the server received M1, M2 two messages, processing these two messages need to establish such a correspondence as A->M1, b->m2. Now the practice is to use the session to identify the message, each session has a session ID, the session ID is generated by the server, the server to ensure its uniqueness, the client and the server between the communication process, each message to take this it. The session has an expiration time and the session needs to be re-established after it expires.

Session Store

Session data has a few features:

1. Single data volume is small, each session data is generally within 256Byte.

2. The total size of the data increase slowly, every 100w session is about 300MB.

3. High frequency of reading and writing. Compared to other data, the session reading and writing rate is likely to be the highest, because each message will trigger at least once the session read-write.

Based on the above 3 characteristics found that the session in memory is the most cost-effective, occupy little memory space, read and write fast. If the session expiration time is 1 days, the system is active with 100W users, storage session space is 300MB, the magnitude of the server is very easy to say. I recommend the use of Redis storage session, both to meet the requirements and simple.

User state Management

In a system, there are generally two types of users: anonymous users and registered users.

Users are not logged in after entering the system is anonymous users, this time need to use the session to mark the user's temporary data. For example, an e-commerce website can add items to a shopping cart without logging in, and the data in the cart is temporary data, which is deleted when the session expires.

After the user enters the system to log in, at this time this user is the registered user, each registered user has a unique user ID, through this user ID, binds the user and the session. In this way, the user ID can be found through the session, and the user's private data is found through the user ID, thus providing various services to the user. Sometimes, there is a user ID to find the session, which requires the user ID and session binding at the same time to establish a user ID to the session of the key-value relationship.

Message forwarding

If there is a need for the access layer to be responsible for message forwarding, there are two procedures for message forwarding: Generating a message and pushing the message. Messages can be generated by a user, such as a user's chat message, or a system-generated ad that you receive when you use an app. After the message is generated, the message is then pushed to the user, and the user is able to receive the message with a long connection between the client and the server. A message can be directed to a specific user or pushed to multiple users, both of which are common. To successfully push a message to the user, first determine which users the message needs to be pushed to, and then find out which access servers these users have established long connections to, and then push the message to the appropriate access server, leaving the connection to the server.

When the access server receives a message that needs to be pushed, it will find the session based on the target user ID in the message header, remove the long connected socket file descriptor from the session and send the message. It's not a problem in theory, but it's easy to make mistakes. On Linux, the socket file descriptor is used in a loop. If user A's connection is short, if User B establishes a connection before using a reconnection, User B's Connection file descriptor is the same as the user's previous user A. The message that you are trying to push to a at this point will be pushed to B. The solution to this file is for each connection to be established, the file description Fuzhou into a serial number that will not repeat for a longer period of time, using this serial number to find the file descriptor.

Background Development Technology (2)--Access layer design