Mqant Framework Overview

This is a creation in Article, where the information may have evolved or changed.

Mqant after 4 months of development, now on GitHub has won more than 300 star, I believe in the efforts of everyone mqant will be more glorious in the future

Today, only a multi-process architecture can support more online users, reduce server pressure, reduce the impact of a single point of failure, and so on, so a truly highly scalable game running architecture must be multi-process.

However, the development and operation of the game is carried out according to the steps of the stage, especially now the server hardware equipment configuration is also more and more high premise, when the game is just beginning to operate a single server is enough to support, and multi-process deployment brought about by the operation and maintenance costs are relatively high.

The idea of mqant is that when a single server can be used, the performance of the server can be fully tapped, and distributed deployment can be achieved with a simple configuration when multiple processes are required.

Mqant The running architecture of the game server

Mqant server is divided into modules according to the module, such as user management, online chat, combat platform, etc. should be divided into separate modules

Through RPC communication between modules, the Mqant base will choose the communication channel of RPC data interaction according to the actual situation, and use Golang Chan communication directly in the case of the same process in the calling module, so the communication performance is not affected with the in-process module.

Each module can register multiple processors (handler), the processor is divided into backend/frontend two modes

Frontend provided to the client to invoke the

Backend provides a back-end module that calls each other

Frontend's agreement

Frontend and backend are actually the same, the only difference is that we agreed to frontend named "Hd_" opened, while the frontend function of the parameter type is also fixed

Mqant Game Server Architecture

Inter-module Communication RPC

RPC in Mqant is encapsulated as a common interface, and the underlying can switch to other RPC channels, such as GRPC,ZERORPC, as required, but the remote communication channel currently used by Mqant is RABBITMQ Message Queuing.

Why this choice?

Select Message Queue instead of traditional tcp/socket RPC The main consideration is the traditional point-to-point service/client mode connection is difficult to maintain and statistics, if the server has 100 modules and servers, in a process need to maintain the client connection >100 (calculation may be less accurate (-^)).

and select Message Queue each process for each module only need to maintain a connection, while RABBITMQ has a sound monitoring, alarm tools, can monitor the module's processing performance and real-time ability at any time.

In addition to the problem that Message Queuing may face bottlenecks in message forwarding, Mqant is able to configure its own Message Queuing server individually per module, so that it can scale horizontally in the future