前言
项目不同，架构自然也不同，所以没有唯一的架构，只有合适项目的架构。
这章以休闲类手游为例。
1：架构图
2张差别，就是中间件
用中间件 主要 异步化提升性能、降低耦合度、流量削峰
根据需求选择一种服务器间的消息转发模式（业务简单明确可以选择RPC，复杂 可以选择MQ (NSQ或kafka) 等）
中间件也是有承载度的，N组(业务不同) 一个，公司某游戏采用下面这种

2：说明

1>前端登陆过程
<1>通过SDK 取得TOKEN
<2>链接登陆服务器，发送sdk返回的token 可加其他参数
<3>验证OK，得到token gate地址 可加其他参数

2>服务器处理过程
<1>登陆服务器(验证服)，把token等去平台校验完成后，把 gate 地址（根据ETCD 健康度 及 上次登录的网关 选择），token 等
注意点 在玩家没下线时 一定选择上次网关 ，这样好挤号；
<2>gate服务器，把前端过来的token的校验下（免查询校验),完成后，把唯一账号给hall ，gate也需要限流，
<3>hall 通过DB/Redis查询得到角色数据 通过gate 发送给前端
<4>match 服务器 ，配队后，通知battle 创建战斗房间，同时通知前端 战斗房间地址及token ,match 可以按匹配类型进行 分类，如果量还大，继续细分
<5>战斗服务器，验证前端信息后，放进战斗房间 ，及时性要求高就直连，要求不高 可以gate 转
<6>聊天服务器，处理聊天信息 量大 图省事 可以直接使用开源 IM 系统,
<7>工会服务器，处理工会
<8>GM服务器， 处理官方人员的操作
<9>其他服务器 按需增加

3>中间件
增加中间件 降低耦合度、流量削峰 ，但是也增加延时 ,还有就是规模小时根本用不上，中间件 需要的内存，磁盘 要求较高，根据业务量 部署较好

4> 动态增加/退出服务器 ETCD一般设置3个就够用了
NoSQL（redis） 在线人数不是特别多 主从也可以，集群 量没上来浪费资源,上来了，找个时间重启一次就好了
增加 没什么要说的
删除 的话需要 遵守 类试 nginx, 老节点（新的用户不给这个节点了） 继续处理 ，处理完就可以退出了（也可以根据时长及 在线用户量 手动KILL掉，总不能有几个用户在挂机就一直留着 吧）
(1)登录服 一般都是短连接，采用 DNS轮询，随时增加服务器， 建议 采用 gin 或 openresty 增加 单IP 个数限制及并发限制
根据健康度 及客户端版本 选择适合的gate, 灰度更新也在这里
(2)GATE HALL 根据 需要，随时增加 或删除，增加后 注册到ETCD即可
(3)匹配服 根据人数/阶段 可以进行 细分 ,随时增加/删除 设计好健康度就行
(4) DB 又是老问题，预估注册人数，及在线人数，不太多，可以 双主从 ，多的话，还是直接集群吧
redis 与DB 同步，要求不搞，如果是mysql, 直接 Binlog同步，什么延迟双删，估计日志/数据 里出点异常，就怀疑到这里，难折腾。
数据备份 重要重要重要 一般周 一次全量， 其他增量
（5） MQ类，kafka 作为 日志处理是很好用的，玩家的日常行为，战斗，充值记录等，
作为 服务 间 解耦 看业务及并发量
（6）监控 很重要，推荐 Prometheus +Grafana
（7） 部署与运维 看数量，极少时，随意， 一般docker + docker-compose , 大量 K8S等，这个小公司用不起（米米没赚够高，没必要上）
（8） 休闲游戏 ，如果连100K 都没以后，没必要搞这个架构，100-500K 需要根据量 增加分库，及集群
（9） 登录/验证服 如果备攻击得厉害，建议上高防，GATE ,BATTLE 可以用动态端口
短连接 请求可以加噪声 ，长连接 设计好 消息 加流水号 噪声 等
还有可以用区块链技术去 增加攻击/作弊成本

3:日志
比较推荐采用 kafka+elk+filebeat(或自定义)
容器工具 可以试下 podman+buildah+kopeo
Kubernetes(k8s)+Containerd