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

2：说明

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

2>服务器处理过程
<1>登陆服务器，把token等去平台校验完成后，把 gate 地址，token 等
<2>gate服务器，把前端过来的token的校验下（免查询校验),完成后，把唯一账号给hall
<3>hall 通过DB/Redis查询得到角色数据 通过gate 发送给前端
<4>match 服务器 ，配队后，通知battle 创建战斗房间，同时通知前端 战斗房间地址及token ,match 可以按匹配类型进行 分类，如果量还大，继续细分
<5>战斗服务器，验证前端信息后，放进战斗房间
<6>聊天服务器，处理聊天信息
<7>工会服务器，处理工会
<8>GM服务器， 处理官方人员的操作
<9>其他服务器 按需增加

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

3:日志
比较推荐采用 kafka+elk+filebeat
容器工具 podman+buildah+kopeo
Kubernetes(k8s)+Containerd