Today, I will share with you the server architecture of Tencent's game "The Legend of Xuanyuan". If the server architecture is only a result, it is meaningless to show the schematic diagram of the architecture. Today I want to start from the simplest architecture that everyone can write. The model, how to evolve step by step into the division and world structure of "The Legend of Xuanyuan".
Function Extensibility Segmentation and Operation and Maintenance Extensibility Segmentation
The simplest game server, one process handles all the functions, such as supporting 500 people online at the same time, opening a server A corresponding to the player called ClientA, Server a process, the structure is as follows: ClientA------>Server. What should I do if I start a second server B?
Option 1: One server process supports players from two servers to play at the same time, ClientA/B---->ServerA/B. The advantage of this is that cross-server communication is very convenient. In one process, the disadvantage is that players on ClientA server The resulting downtime will affect players on server B. The same process to run the A area, B area, can not take advantage of the multi-core server. Then it will evolve into option 2.
Option 2: Players on server A are served by the ServerA process, players on server B are served by the serverB process, and they are deployed on one machine. The advantage of this compared to scheme 1 is that the expansion is realized on one machine. The disadvantage is still obvious that if the physical machine is broken, the players on both servers cannot play normally.
ClientA------>ServerA
ClientB------>ServerB (ServerA, ServerB deployed to one machine)
Then evolve and split to get Scheme 3.
Solution 3: We put different servers on different physical machines, so that different servers are truly independent.
ClientA------>ServerA
ClientB------>ServerB (ServerA, ServerB are deployed to different machines)
To sum up, solutions 1 to 2 are called functional scalability segmentation, and solutions 2 to 3 are called operation and maintenance scalability segmentation.
separate public service
Different servers are deployed on different physical machines, and there are some common services between different servers. Instead of implementing one for each server, each server sets up one, so these public services are separated separately, so the architecture evolves into the following:
At this time, the public server is globally unique and shared by multiple servers, it becomes a single point of failure. What should I do if the public server has a single point of failure? A common solution to a single point of failure is master-standby-slave.
Separate each server by function
Each server mentioned in Xuanyuan above is divided into three layers according to fixed functions: connection layer (tconnd), logic layer (logic srv), storage layer (torm svr) as shown below
Then the ensuing problem comes again. Logical processing and data persistence on a physical machine will cause the file IO of the DB to slow down the entire system (million players per server, hundreds of G of data). ). During the running of the process, a large number of logs are output every day, such as Xuanyuan, the daily log volume can reach several gigabytes of data. What's more deadly is that if the physical machine crashes, the business data in the database will be lost at any time. The loss of business data can already be regarded as a serious operational accident during the long-term operation. Therefore, the architecture of each server will undergo subsequent evolution.
Separation by Importance: Separating Logical Computing and Persistent Storage Deployment
Important data in game operation includes log and database data. We say that these important data need to be deployed in persistent storage and separated from logical computing. Important data adopts a master-standby-slave approach to ensure the stability of business data. sex. Then the architecture of each service of our server evolves as follows:
Partition Multi-World Prototype Evolution
Summarizing the above evolution, we have released the entire Xuanyuan architecture diagram for everyone, the storage and logic are separated, and each server is divided into 3 parts according to the function. Cluster-level server, there is only one globally, World-level server, one group per world, each server, including access, logic, and storage. The storage should be separated, and the DB and DR should be done well.
Further separation of public service
The general structure has been settled, the next step is to separate some functional parts of Xuanyuan, first to separate the public server. As shown below
We separate some fixed functions of the public server into different service processes to provide corresponding services, such as directory servers,
Version upgrade, account service, etc. This splits the public service into a set of processes. During operation and maintenance, a set of machines is deployed for the public service according to the operation and maintenance requirements.
Split Xuanyuan logic process
All players in the current server are in one process. The advantage is that it can be easily operated to all players. There are also risks. A bug in one feature will affect all players with other features on the current process. Next, we will split the logical process. The common method of splitting the logical process in MMORPG is to split it according to the scene. Then our architecture evolves as follows, and the logic is split into the world + multiple scenes, as follows:
Let multiple Scenes serve some users respectively, and World is responsible for pulling data and coordinating and controlling all Scenes. The biggest difference between game development and other application development is that when a product is online, it needs to be changed frequently in combination with player operations. It is just the beginning of the launch. All functions and features are in one process, and constant updating of features will make it more stable. Therefore, we split and independent those functions with relatively few updates to increase the risk of updates to system stability.
Summarize
Finally, to summarize, how to segment the game framework, and share some of the summed up experience gained in Xuanyuan for your reference:
For scalability: one set of servers, one set of processes;
For operability: one set of servers, one set of machines;
for reliability: weakly correlated functional separation;
Improve the convenience of updates: separate parts of mundane updates;
Segmentation by importance of services: payment system independence;
Segmentation by service characteristics: access, storage, logical separation;
Divide stable (basic functions) and unstable (business logic)
Well, today's "Legend of Xuanyuan" architecture evolution is shared here. I explained a course in detail. In addition to analyzing the evolution, I also shared some experience in long-term operation and shared it with online games for large players who have never developed. developer of .