游戏服务器架构

一些拓扑：

https://blog.csdn.net/to_be_better/article/details/56954500

 

登陆服务器

---

 https://github.com/cloudwu/skynet/wiki/LoginServer

https://github.com/cloudwu/skynet/wiki/MsgServer

只是负责验证用户名和密码，验证以后返回token，token是有有效时间的，在有效时间内，并无保持链接的必要，因此，这里的RequestResponse能够作成短链接（http请求响应模式），提高并发。


若是超过了有效时间尚未进入游戏，令牌失效，在登陆验证时将被踢回从新获取令牌。


登陆服务器和网关之间须要有一个固定的链接传递新生成的令牌。

 

中心服务器

---

 

管理各类服务器
--------------------------
登记各类服务器
广播各类服务器上线、下线
反映各服务器状态

记录最大在线人数
--------------------------
记录各个服务器的在线（人数\链接数）

 

链接服务器（gateway）

---

 

 处理多链接的服务器

 

网关服务器

---

负责全部客户端的长链接的维护。每个链接都会对应一个session，只有经过登陆验证的session才能将报文传入游戏服务器群的消息队列中。没验证登陆的session须要发送以前从登陆服务器得到的token来验证登陆。

token会和帐号绑定，一旦验证经过，网关将通知游戏服务器新玩家进入，游戏服务器从数据库读取玩家的角色列表数据，再经过网关发送给客户端。

上述的操做多是游戏中最耗时的一步。因此可能增长的策略是异步推送，多人排队等。

也能作这些用途：

客户端发客户端
转发给各服务器
消息链接用的

做用不只仅是转发了，同时也起到隔绝网络的做用（反射代理）。 

 

组播

---

 https://blog.codingnow.com/2007/03/multicast.html

 

Profile

---

https://github.com/cloudwu/skynet/wiki/Profile

 

处理 TCP 的分包

在开发网络游戏时，咱们每每须要按传统，把 TCP 链接上的数据流分割为一个个数据包。将数据流转换为数据包，比较常见的作法是给数据包加一个长度信息，组装在数据流中。

 

游戏服务器

玩家确实进入游戏以后，每个玩家都会有一个对应的Agent来维护。包括玩家的即时游戏数据，存档游戏数据。全部与游戏内容相关的都称为游戏服务器。这部分的工做量将是游戏开发过程当中最大的。


主要就是从网关发送的消息队列中不断读取消息，而后进行处理。对于游戏来讲，整个世界是在一个循环体中的，因此首先确定会有一个大的世界循环体，而后是每一个Agent的存在更新。鉴于如今的网游都没有存档的设计，全是数据统一入库的，因此，Agent还须要负责玩家数据的持久化。我只打算作按期持久化，若是像王者那样即时持久化，须要的代码量和代码的耦合让人不太舒服。




须要的类库
服务器内部的通信，消息队列，由于没有什么须要持久化稳定之类的需求，速度能够提上来，ZeroMQ是极好的。
数据库仍是继续使用MySQL

 

 http://blog.51cto.com/rangercyh/1673922

https://zhuanlan.zhihu.com/p/26252412