前言

项目不同,架构自然也不同,所以没有唯一的架构,只有合适项目的架构。
这里先以手游(房间类)为例。

1:编程语言
golang/c++/rust

2:架构图(手画图有点丑)

3:以2图简述
后端1 是面向前端 链接 的, 后端2 前端不能直接链接 ,中间件 是为后端内部 消息转发用
1>版号服务器
APP启动先检查是否有版本更新,这里可以连版本服务器,对比版本号,从CDN更新
版本服务器可以根据需求,配置N个服务器(一般2,3台就够了,可以采用dns 轮询方式)
或 直接把版号本文件放到CDN(注意同步时间及CDN 缓存设置)
2>登录服务器(游戏类型不同 这里会有差异)
一般APP 都会内接SDK,SDK会去平台(乙方或第三方)进行登录,成功后把返回的参数(一般是类TOKEN 可能带其他参 数)根据需要(类TOKEN是必须的,其他的看接入文档)发送给登录服务器,登录服务器 再去平台请求验证,验证通过后,选区登录或直接给一个gate 地址(根据负载均衡,gate链接量要通知给login) 加上一个登录类TOKEN,可以存放到redis(或集群)里
登录这里可以做黑白名单
3>网关服务器
链接到网关后拿TOKEN去校验,成功后,可以设置位一个新状态
4>代理转发( RPC或 MQ或NSQ)
用中间件 主要 异步化提升性能、降低耦合度、流量削峰
根据需求选择一种服务器间的消息转发模式(业务简单明确可以选择RPC,复杂 可以选择MQ或NSQ)
5>后端2
游戏类型不同,业务模型也不同(可以增删或合并)
GUILD 工会 (可以没有)
LOGIC 逻辑
CHAT 聊天(可能没有,战斗的聊天可以直接在战斗服转发)
DB 数据服(结合REDIS 缓存 存储数据)
MATCH 匹配服 (根据一定规则匹配,分区的,也可以统一匹配)
FRIEND 好友服(可以没有)
TEAM 组队 (可以没有)
6>存储
根据需求 使用redis 群集 ,服务注册与发现(etcd/Consul)
4:战斗服
需要战斗需要低延迟,那么可以用kcp 等
如不需要,可以放到 后端2 ,由GATE 转发
5:后面使用c++/GOLANG/RUST 简单实现
前端使用cocoscreator 做个DEMO