foreword
Different projects have different architectures, so there is no unique architecture, only the appropriate architecture for the project.
Here we take mobile games (room category) as an example.
1: Programming language
golang/c++/rust
2: Architecture diagram (hand-drawn diagram is a bit ugly)
3: Use Figure 2 to briefly describe that
the backend 1 is oriented to the front-end link, and the backend 2 cannot be directly linked to the front-end. The middleware is used for forwarding internal messages at the backend.
1> Version number server
APP starts to check whether there is a version update, here you can Connect to the version server, compare the version number, and update
the version server from the CDN. The version server can be configured with N servers (generally 2 or 3 are enough, and dns polling can be used)
or directly put the version number file on the CDN (note Synchronization time and CDN cache settings)
2> Log in to the server (there will be differences depending on the game type).
Generally, the APP will connect to the SDK, and the SDK will go to the platform (Party B or the third party) to log in. After success, the returned parameters (usually the class TOKEN may have other parameters) according to needs (like TOKEN is necessary, see the access document for others) and send it to the login server, and then go to the platform to request verification after logging in to the server. Balanced, the amount of gate links should be notified to login) Add a login TOKEN, which can be stored in redis (or cluster). Log in here
to make a black and white list.
3>
After the gateway server is connected to the gateway, take the TOKEN to verify. After success, you can Set a new state
4> Proxy forwarding (RPC or MQ or NSQ)
uses middleware to mainly asynchronously improve performance, reduce coupling, and traffic peak shaving.
Choose a message forwarding mode between servers according to requirements (if the business is simple and clear, you can choose RPC , you can choose MQ or NSQ for complexity)
5> The backend 2
game types are different, and the business models are also different (can be added, deleted or merged)
GUILD union (can be absent)
LOGIC logic
CHAT chat (probably not, battle chat can be forwarded directly in the battle server)
DB data server (combined with REDIS cache to store data)
MATCH matching server (matching according to certain rules, partitioned, or unified matching)
FRIEND friend server (optional)
TEAM teaming (optional)
6>Storage
Use redis cluster, service registration and discovery (etcd/Consul) according to
requirements , reposted by GATE 5: Simple implementation using c++/GOLANG/RUST later, using cocoscreator as a DEMO on the front end