前言
項目不同，架構(gòu)自然也不同，所以沒有唯一的架構(gòu)，只有合適項目的架構(gòu)。
這章以休閑類手游為例。
1：架構(gòu)圖
2張差別，就是中間件
用中間件 主要 異步化提升性能、降低耦合度、流量削峰
根據(jù)需求選擇一種服務器間的消息轉(zhuǎn)發(fā)模式（業(yè)務簡單明確可以選擇RPC，復雜 可以選擇MQ或NSQ或kafka 等）
中間件也是有承載度的，N組(業(yè)務不同) 一個

2：說明

1>前端登陸過程
<1>通過SDK 取得TOKEN
<2>鏈接登陸服務器，發(fā)送sdk返回的token 可加其他參數(shù)
<3>驗證OK，得到token gate地址 可加其他參數(shù)

2>服務器處理過程
<1>登陸服務器，把token等去平臺校驗完成后，把 gate 地址，token 等
<2>gate服務器，把前端過來的token的校驗下（免查詢校驗),完成后，把唯一賬號給hall
<3>hall 通過DB/Redis查詢得到角色數(shù)據(jù) 通過gate 發(fā)送給前端
<4>match 服務器 ，配隊后，通知battle 創(chuàng)建戰(zhàn)斗房間，同時通知前端 戰(zhàn)斗房間地址及token ,match 可以按匹配類型進行 分類，如果量還大，繼續(xù)細分
<5>戰(zhàn)斗服務器，驗證前端信息后，放進戰(zhàn)斗房間
<6>聊天服務器，處理聊天信息
<7>工會服務器，處理工會
<8>GM服務器， 處理官方人員的操作
<9>其他服務器 按需增加

3>中間件
增加中間件 降低耦合度、流量削峰 ，但是也增加延時 ,還有就是規(guī)模小時根本用不上，中間件 需要的內(nèi)存，磁盤 要求較高，根據(jù)業(yè)務量 部署較好

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