Shulou(Shulou.com)05/31 Report--

This article mainly explains the "classic game server-side architecture case analysis", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next let the editor to take you to learn "classic game server-side architecture case analysis" bar!

The analytical model of the architecture one. The background of the discussion

Modern video games basically use certain network functions. From verification to multi-person interaction, it is necessary to set up some dedicated servers and programs written on the server. Therefore, the software architecture of the game server is essentially the software architecture of the specific field of the game server.

The analysis of software architecture can be done at different levels. The more classic software architecture description includes the following architectures:

Runtime architecture-this architecture is concerned with how to solve the problem of running efficiency, which is usually expressed in the form of program process diagram and data flow diagram. The runtime architecture is included in the architecture design documents of most development teams, indicating that this is a very important design aspect. This architecture will also significantly affect the development efficiency and deployment efficiency of software code. This article mainly discusses this architecture.

Logical architecture-this architecture is concerned with the relationship between software code, the main purpose is to improve the convenience of software to respond to changes in requirements. People often use class diagrams and module diagrams to express this architecture. This architectural design plays a vital role in projects that require long-term operation and high reusability. Because the scalability and reusability of the software are basically determined by the design of this aspect. Especially in the game field, the frequency of demand change can be said to be the highest in many areas of the Internet industry. This article will cover part of this architecture, but it is not the focus of this article.

Physical architecture-care about how the software is deployed, with computer rooms, servers, and network equipment as the main description objects.

Data architecture-concerned about the design of the data structure involved in the software, which is of great significance for data analysis and mining and multi-system cooperation.

Development architecture-concerned about the relationship between software development libraries, as well as version management, development tools, compilation and build design, mainly to improve the efficiency of multi-person collaborative development, as well as complex software library references. Now the popular integrated construction system is a theory of development architecture.

two。 Elements of the game server architecture

The essence of server-side software is a program that will run for a long time, and it also serves a number of network requests with indefinite time and location. So the characteristic of this kind of software is to pay great attention to stability and performance. If such programs need multiple collaborations to improve their carrying capacity, they should also pay attention to the convenience of deployment and expansion; at the same time, they also need to consider how to achieve some degree of disaster recovery requirements. Due to the cooperation of multi-processes, it also brings the complexity of development, which is also an issue of concern.

Functional constraints are the decisive factor in architecture design. An omnipotent structure must be an incompetent one. An excellent architecture is generated by grasping the core functions of the corresponding business areas. The functional features of the game field, for server-side systems, are clearly represented by the requirements of several functions:

For storage of game data and player data

Broadcast data to the player client

Part of the game logic is calculated on the server to facilitate the game to update the content and prevent plug-ins.

In view of the above demand characteristics, in the server-side software development, we often pay attention to the use of computer memory and CPU, in order to meet the needs of load capacity and response delay under the specific business code. The most basic approach is "time-space conversion", using a variety of cache ways to develop programs in order to achieve the right balance between CPU time and memory space. On top of CPU and memory is another constraint: the network card. Network bandwidth directly limits the processing power of the server, so the game server architecture must also consider this factor.

For game server architecture design, the most important thing is to make use of the demand constraints of game products to optimize the "time-space" architecture that is most suitable for this particular function. And minimize the use of network bandwidth.

[figure-Analysis Model of Game Server]

three。 Three core architectures

Based on the above analysis model, for the game server architecture, the three most important parts are how to use CPU, memory and network card design:

Memory architecture: mainly determines how the server uses memory to ensure as few memory leaks as possible, and maximize the use of server-side memory to increase load capacity and reduce service latency.

Scheduling architecture: design how to use processes, threads, and co-programs for CPU scheduling. Different programming models such as synchronous and asynchronous are selected to improve the stability and carrying capacity of the server. At the same time, we should also consider the complexity of development. The emerging virtualization technologies, such as virtual machines, docker, cloud servers, and so on, provide more options for scheduling architecture.

Communication mode: decide how to communicate. Network communication includes the choice of transport layer, such as the choice of TCP/UDP; expression layer, such as defining protocol, and the interface design of application layer, such as message queue, event distribution, remote invocation and so on.

The discussion of this paper mainly focuses on the analysis of the above three architectures.

four。 The Evolution of Game Server Model

The earliest game server is relatively simple, such as UO "Network Genesis" server side of a 3.5-inch floppy disk can be saved. It's basically just a server program that broadcasts and stores files. Later, due to the popularity of plug-ins and piracy in China, game manufacturers began to use MUD as a model to establish an architecture that mainly runs logic on the server side. This architecture is carried forward in the continuous update of MMORPG products, which leads to the emergence of distributed game servers designed with distributed elements such as map, field of vision and so on. In another area, casual games, the natural need to focus on ultra-high online users, so regional architecture began to emerge. Modern game server architecture basically hopes to be designed with the combination of carrying capacity and expansibility, thus forming a more rich and diverse form.

The main purpose of this paper is to select these typical game server models and analyze the advantages and disadvantages of their underlying choices, hoping to explore a more extensive and more efficient server model.

Sub-service model one. Model description

The sub-server model is the most typical and the oldest model in the game server. Its characteristic is that the game server is a separate world. The account of each server is independent, and only the account of the same server can generate online interaction. When the capacity of the early servers reached the limit, game developers solved the problem by setting up more servers. This provides the "parallel worlds" of many games and creates more space for the comparison between people in the game. So later, with the opening and merger of servers, a set of mature operation means was formed. A technical choice finally leads to the mode of game operation, which is a very interesting phenomenon.

[figure-single process scheduling model]

Synchronous-dynamic multithreading: each time a user session is received, a thread is established. This user session is often represented by the client's TCP connection, so that every time a packet is read or written out from a socket call, blocking mode can be used and the coding is intuitive and simple. There are as many threads as there are connections to the game client. However, this scheme also has obvious disadvantages, that is, the server is easy to generate a large number of threads, which is difficult to control the memory occupation, and thread switching will also cause the performance loss of CPU. More importantly, the reading and writing of the same piece of data under multithreading needs to deal with the problem of lock, which may make the code very complex, resulting in a variety of deadlock BUG, affecting the stability of the server.

Synchronous-multithread pool: in order to save the establishment and release of threads, a thread pool is established. When each user session is established, apply to the thread pool for the use of processing threads. At the end of the user session, the thread does not exit, but "releases" the use of the thread to the thread pool. The thread pool can well control the number of threads, prevent the connection impact on the server caused by the surge of users, and form a queuing mechanism. However, the implementation of the thread pool itself is more complex, and the calling rules of "apply" and "release" threads need to be strictly followed, otherwise there will be thread leakage and depletion of the thread pool.

Asynchronous-single thread / co-program: in the game industry, using Linux's epoll as the network API, in order to get high performance, is a common choice. The most common blocking call in the game server process is the network IO, so after adopting epoll, the whole server process may become completely unblocked, so only one thread is needed. This completely solves the lock problem of multithreading and simplifies the difficulty of concurrent programming. However, the "all calls must not be blocked" constraint is not so easy to comply with, for example, the API of some databases is blocked; in addition, a single process and single thread can only use one CPU, which cannot make full use of CPU resources in today's multi-core and multi-CPU servers. Because asynchronous programming is based on "callback", it will lead to many callback functions to be defined, and the logic in a process will be written in several different callback functions, ignoring code reading. To solve this kind of coding problem, Coroutine can help better, so now it is more popular to use the combination of async and co-programming. In any case, the asynchronous-single-threaded model is still the first choice for many teams because of its good performance and no need for concurrent thinking.

Asynchronous-fixed multithreading: this is an evolved model based on the asynchronous-single-threaded model. This model generally has three types of threads: main thread, IO thread and logical thread. These threads run internally in a fully asynchronous manner, and they communicate through unlocked message queues.

Multi-process game server

Multi-process game server system originated from the demand for performance problems. Because under the single-process architecture, there is always a limit of carrying capacity, the more complex the game, the lower the single-process carrying capacity, so developers must break through the process restrictions in order to support more complex games.

Once on the road to multi-process, developers also found some other benefits of multi-process system: the ability to take advantage of multi-core CPU capabilities; the use of operating system tools to monitor the running status more carefully and easier to deal with disaster recovery. The classic model of multi-process system is "three-tier architecture":

In a multi-process architecture, developers generally tend to develop the functions of each module into a separate process, and then use inter-process communication to coordinate and deal with the complete logic. This idea is a typical "pipe and filter" architecture pattern-each process is treated as a filter, and the data packets sent by the user flow through multiple filters to form a pipeline, and finally be processed completely. Because multiple processes are used, it is preferred to use a single process and a single thread to construct each of these processes. In this way, for program development, the structure is much clearer and simpler, and higher performance can be obtained.

[figure-object tree architecture]

In the Objective C language, there is a feature called autorealse, which is actually a reference counting technique. Because it can cooperate under a certain scheduling model, it will be easier to use. In the same way, some developers will use some smart pointers to work with their own framework to clean up the relevant memory at once after the complete business logic is called.

[figure-pre-allocated memory pool]

However, there are also some disadvantages: first, it is not easy to deploy. For example, if you want to deploy a set for testing on a virtual machine with fewer resources, a person may not change the size of the memory pool, resulting in unsuccessful startup. This configuration needs to be modified each time the environment is changed. Second, all class objects used must have a pointer or reference in the root node object, otherwise memory may be leaked. Because for non-basic types of objects, we generally do not like to use copy as function parameters and return values, while pointers and applications point to memory, if not new, can only be off-the-shelf member properties of an object. As a result, the more complex the program, the more member attributes of this class, which can be a burden on code maintenance.

To solve the above shortcomings, you can modify the implementation of the memory pool to grow dynamically, but the model with an upper limit will only new each time an object is "fetched" from the memory pool. This avoids problems that cannot be started on small memory machines. For the problem of complex object attributes, it is generally necessary to plan the code according to the object-oriented principle, so as to minimize the use of attributes that only represent function parameters and return values, but mainly record the "business state" attributes of the object. spend more effort on building the data model of the game.

four。 Means of interprocess communication

In a multi-process system, how to communicate between processes is a crucial issue, and its performance and convenience directly determine the technical efficiency of the multi-process system.

Socket communication

TCP/IP protocol is a universal, cross-language, cross-operating system, cross-machine communication scheme. This is also a means that developers first think of. In use, there are two options: TCP and UDP. Generally speaking, we tend to use TCP in the game system, because the logical correlation of the game data is relatively strong. Because of the possible packet loss and retransmission processing, the processing of UDP in the game logic is generally more complex. Because the inter-process network of multi-process system is generally good, the performance advantage of UDP will not be particularly obvious.

To use TCP for cross-process communication, the first thing is to write a TCP Server for port listening and connection management; secondly, you need to customize the protocol for the communication content that may be used; and finally, you need to write the logic of codec and business logic forwarding. After all this is done, it can really be used as a means of inter-process communication.

The advantage of using Socket programming is that it is versatile and you can use it to implement any function and collaborate with any process. But its disadvantage is also very obvious, that is, the amount of development is very large. Although there are some open source components that can help you simplify the writing of Socket Server, connection management and message distribution, choosing a target to establish a connection and customizing the protocol codec are often done by yourself. The game is characterized by a lot of changes in business logic, resulting in a large amount of work to modify the protocol. So in addition to using TCP/IP socket directly, there are many other options we can try.

[figure-message queue]

It should be noted that some developers are inexperienced and use less efficient media such as MySQL or NFS to store queues. Although this is functionally feasible, it is difficult to play a role as soon as the operation is frequent. For example, in the past, some mobile SMS applications used MySQL to store "to be sent" text messages.

Although message queues are very easy to use, we still have to encode and decode the messages ourselves and distribute them to the required handlers. There is a transformation and corresponding work between the message and the handler. Due to the variety of game logic, this kind of corresponding work depends entirely on manual coding, which is relatively error-prone. So there is room for further improvement.

Remote call

Some developers will want to completely block whether cross-process calls are made during coding, just like calling local functions or local object methods. So there are a lot of remote call schemes, the most classic one is Corba scheme, which tries to achieve remote calls directly in code in different languages. The JAVA virtual machine comes with the support of RMI scheme, so it is convenient to call remotely between JAVA processes. In the environment of the Internet, there are various Web Service schemes, which take HTTP protocol as the bearer and WSDL as the interface description.

The biggest advantage of using remote calls is the convenience of development. You only need to write a function to call this function on any other process. For game development, this solves one of the biggest development efficiency problems of multi-process solutions. But this convenience comes at a cost: in general, the performance of remote calls is slightly worse because a unified codec scheme is required. If you are using a static language such as CCompact +, you also need to use an IDL language to first describe the interface of this remote function. But the benefits of these difficulties are well worth it in the field of game development.

[figure-Server status Management]

Although most of the disaster recovery and expansion requirements can be achieved with a simple directory server, the problem is more complicated if there is data in the memory of the accessed process. For disaster recovery, the new process must have a way to reconstruct the data in the memory of the "invalid" process in order to complete the disaster recovery function. For the expansion function, the newly added process must also be able to load the required data into its own memory, and this data may already exist in other parallel processes. How to transfer this part of the data? it is a relatively performance-consuming and requires a lot of code to write. So in general, we like to expand capacity and disaster recovery for "stateless" processes.

At this point, I believe you have a deeper understanding of the "classic game server-side architecture example analysis". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.