An SNS strategic casual game development Note 01-distributed system logic Architecture Design

Document directory

• Statement:
• The process for gamers to play the game is as follows:
• Heartbeat protocol design
• Specific development and design requirements

Recently, I participated in the development of a casual SNS game. Now I have just completed the internal demo version. The main task of the demo is to try a brand new gameplay and test some client technologies. Since the demo version was successfully created, we have to go further.

This game is a real-time online game with frequent user operations and high server response requirements. Therefore, before the development of the "Upgrade" demo version, I carefully considered the logic architecture of the server. In order to further clarify the ideas, I would like to pay tribute to the bloggers.

Although I have occasionally made "contributions" to my blog, I am still a pure winner ". However, this time, we are determined to summon the courage to carefully prepare "Development logs" for every stage of game development. please supervise it.

 

Statement:

1. In order to safeguard the company's interests, this article only talks about some technologies and does not mention any game logic and rules, let's think of it as an instant strategy version of Happy Farm. Sorry!
2. The term "server" in this article is a logical concept, equivalent to a process.

 

Basic game needs	Development Requirements	Solution/SOLUTION
Integration with SNS	The client can only use Web Technology	Flash + HTML + JS
It is a "big world" like a happy farm"	The server must be able to scale out and scale up to increase the load capacity by adding machines.	Hierarchical and distributed architecture,
Multiplayer instant strategic games (online interstellar)	The server must respond quickly and have high stability. The demand for data storage is not great. You only need to record user information, combat results, and items.	Use a good network I/O model and an optimized combat service (device ).

 

In view of the above challenging demands, I feel more excited at the same time! I have always been interested in distributed development, but I have also done some experimental development, but I have not yet succeeded in commercial operation project experience. As a technology, what is more exciting than this? I even think of happy farm as a server group... Give yourself a goal first!

After studying my own experiment project and referring to the experiences of countless cool guys, I started planning... The topic of "Notes" is officially entered below.

 

The process for gamers to play the game is as follows:

1. log on to the SNS website;
2. Connect to the login server and log on to the game;
3. Connect to the game server;
4. Connect to the combat server after determining to start an instant fighter on the game server;
5. Start Step 4 after the battle ends or return to Step 5.

 

Our server architecture includes the following components)

	Services and components	Function	Thread Model	Status	Port	Special requirements
1	Web Server (Web)	A. Game interface bearer B. Resource file * Select a login server based on the load data	Multithreading + heartbeat	Yes	80	High traffic
2	Login Service (LS)	A. Perform logon verification for the user B. Create a user role for a new user C. Select an idle game server based on the Load Distribution Algorithm. The server returns to the client and connects to the game server. D. Other functions	Multithreading + heartbeat	Yes	12012 12022	Simple logic, connection Creation Frequent website destruction
3	Game Service (GS)	A. All the logic of the non-combat Process B. Start the war	Multithreading + heartbeat	Yes	12013 12023	High Io traffic
4	War Service (WS)	A. Combat Data Processing B. Save combat data	Multithreading + heartbeat	Yes	12014 12024	Small datagram but send and receive Frequency and high response requirements
5	IM service (Is)	A. chat service B. System message broadcast C. Game Data Broadcast This function is called by the play operation)	Multithreading + heartbeat	Yes	12015 12025	--
6	Slave proc (SP)	A. Start/restart, stop services required by MS B. Update the Service Program	Single thread + heartbeat	Yes	12011 12021	Self-starting
7	Master Service MS)	A. Manager slave, including Service (device) to monitor the status of each service. Heartbeat protocol B. Console, which provides the life cycle for operations on each server Command INTERFACE C. Name Service D. status query, status query, for each service For centralized query and HTTP-based logging Rest Mode E. Implement Load Balancing policies and provide For Load query and distribution.	Multi-thread + heartbeat reception	Yes	12010 12020	Self-starting
8	Session servers (Ss)	A. data sharing and interaction between services (servers)		Yes	12016	Use memcached + Key-value DB Implementation
9	Cache servers (CS)			Yes	12017	Use memcached Server Server
10	Database servers					MySQL is mainly used. Applications that can be combined with nosql data
* SP is a scheduling process that must be executed on every server except for ms. * Port 1201x is the service port * Port 1202x is the stats port. Each Service provides status services and Query Interfaces in the form of HTTP + rest.

 

 

Heartbeat protocol design

1. Almost all services regularly send heartbeat to ms, and the server also regularly checks the heartbeat status of each service.

 

2. Heartbeat message content
A. the sender's time to prevent fake heartbeat caused by message Accumulation
B. Service start time and Current Load

3. Heartbeat check
The heartbeat sending interval of a.s is t, and the check interval of C is T.
B. If the most recent Heartbeat message is sent earlier than the NOW-2T, s becomes invalid
C. t should be used to tolerate network latency, machine time difference, and time jump.

4. Key Points
A. Do not initiate a "Heartbeat thread" separately to send messages in the worker thread"
B. Use the same connection as the business message. Do not use "Heartbeat connection" alone"

Specific development and design requirements

1. Standardize the entire framework, that is, to form a reusable distributed development framework to facilitate the development of other projects. It may also be open-source, "chuangfu" society.

2. It should be based on open-source technologies and open-source platforms

3. All the multi-threaded Service server development model: Event loop per Thread + NON-BLOCKING Io

4. Implement "design for failure" and "failover"

5. Slave must be able to reconnect to MS and automatically restart with the machine

6. Emphasize the name servie application. All configuration files use SERVICE_NAME for server configuration.

7. Analyze and classify the execution frequency and execution time of various processing logic in a service, and try to use different threads for different types of logic to improve response performance.

 

The architecture planning is like this, and the program design will be carried out next. Finally, attach a sketch drawn with a tablet (dare to accept new transactions, ^ _ ^)