服务器架构-架构图（一）

前言

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

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