A sns strategic casual game development Note 01-supplement and Discussion of distributed system logic Architecture Design

After posting the article "a sns strategic casual game development Note 01-Distributed System Logical Architecture Design ()", I was very happy to receive some bloggers, in addition, some friends enthusiastically gave some suggestions:

@ Phantaci.com: "We recommend that you design a DB front-end. The DB front-end is used to connect multiple databases of the game. The DB front-end is a data access proxy server ."

@ Black suggestion: "After logon, all interactions must be handled through internal communication. Otherwise, the chances of being changed are very high.

Supplement: I don't know if you have done SF yet. All games can only be handled by one external gateway to prevent data tampering"

@ Huadiao tips: "If I do plug-ins, I will do it here

4 war service (WS)

A. Combat Data Processing
B. Save combat data
Experience, money, or something"

 

In yesterday's software development and design, the architecture of this game development is also getting finer and finer. This article not only supplements the previous article but also responds to the suggestions of several friends.

 

I. Data Access

I plan to use the database as the primary data storage, and configure the cache server with the prefix, and write a DB proxy in the program, for MySQL Master read/write splitting and later sharding processing.

If you have experience processing MySQL sharding, Please give some suggestions or open-source product recommendations.

 

Ii. single point of failure

From the above architecture table, the master server (MS) is a single node, logically a single point of failure, how to deal with it? This is our plan. In order not to affect the development progress, and now it is too complicated to consider, it increases the development difficulty and investment costs, so we do not consider solving it in the early development stage, if there are a large number of players after the launch and operation, consider hardware hot standby and start software design and development.

 

3. How many connections are used or switched during the entire game process?

There are two solutions to this problem:

1. The client only connects to the gateway server, that is, the client <----> gateway server <----> backend server group

2. The client uses different functions or different stages to connect to different servers, and one or more connections at the same time, that is, the client <----> Login Server

Client <----> game server

Client <----> war Server

We still plan to adopt 1 + 2, namely: client <----> Login server; client <------> gateway server <----> backend server group

This advantage is:

1. logging on to the server can serve the entire game world, which is more conducive to saving hardware costs.

2. Gateway encapsulates all the processing in the game background and supports more flexible load balancing, which is theoretically more secure.

 

3. We are still confused about the security issues suggested by @ and @. Development is distributed and can be added at the end, I would like to share with you the inherent security limitations of web games:

1. Both JS + HTML and flash technologies are well-viewed source code. No matter what encryption algorithms or methods are used, these are inherent limitations for web games.

2. Because the code is visible, it seems that using any means to encrypt data packets only adds a little more complexity. Please discuss the solution of webgame and secure data transmission on the server.

3. In addition, because of this project (instant online strategy, like Starcraft), server-side data verification or data control methods like other turn-based games do not work for this project.

 

4. The above mentioned a big architecture plan, followed by software development. In order to save the company's development resources, we divide the entire project into three major parts: basic public components/library development, service management service development (MS, SS, etc.), game Service Development (LS, GS, Cs, WS, etc ). After all, you need to develop

1. First, design some infrastructure:

A. Basic communication components or libraries required for communication between services

B. Message protocols, including message bodies, encapsulation, distribution, processing, filtering, encryption, and scaling

C. each service must adopt a uniform development interface and development model, including service start, stop, pause, restart, upgrade, and heartbeat sending. All services will be developed in the form of DLL plug-ins, development prerequisites and basics of application services