服务器架构-架构图(三)

前言
项目不同,架构自然也不同,所以没有唯一的架构,只有合适项目的架构。
这章以休闲类手游为例。
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

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值