Large Server Architecture Discussion

Recently participated in a large server architecture discussion activity and recorded a summary of the experience

The game client uses Cocos2dx-lua's pure LUA authoring logic, and the server uses Golang as the development language

The game type is similar to COC, so there is no need to choose. Need to work with a large server schema for database processing

Use MongoDB to do persistent storage, Redis do cross-service communication data exchange

The use of Ucloud cloud technology eliminates the annoying operation and maintenance work Communication and protocol

Client and server communication using HTTP short connections, JSON-based data packet protocol

Large number of servers using Golang-JSON+RPC for communication server types

Server types are broadly divided into logical servers, combat servers, central server logical Servers

Logical server responsible for daily logic and public logic processing (Friends, guild)

1 logical servers corresponding to a zone, N-zones use Ucloud cloud MongoDB for data storage Combat Server

The battle server is a cluster, and the cluster returns a server with the lowest load return using

The battle server is logically multiplexed through CGO technology and the client C++/lua's battle logic, which is technically

Calibration Center Server for battle logic

Before the client logs in, obtain a login logical server address here at the hub server, while doing a load balancing

Short Connection Evaluation

As the technology of the operating system tends to stabilize, the game architecture tends to be simple due to the weak interaction of the hand-tour. Therefore, Network load is no longer the bottleneck of game server technology. From experience, game server technology, more important is to look at the database selection and processing methods.

Although MongoDB does not perform as well as the memory database. However, it is simpler and safer to store security than a personal-built memory database.

In addition to the cloud technology, performance bottlenecks and operational complexity of the technology to solve

Redis is used for cross-service data interaction that's a good data intermediary, guaranteed speed and stability, definitely not the wheel can match

Short connections are easier to handle on hand than long connections, and do not need to be disconnected. The bottom of the server is also guaranteed by the Golang Framework library. So there is no problem with the load. The server uses JSON for data exchange both internally and externally, simplifying protocol processing. Also facilitates the commissioning

The performance loss of JSON RPC can be negligible for the entire logic processing

Large Server Architecture Discussion