一个还处于空想阶段的服务器结构

 一. 设计思路

a) 以每个模块都具有横向扩展性为设计基准(每个模块都可以通过灵活增加数量的方式来扩容,分担压力---除了Nginx 和 DB, 这两个是瓶颈点. 达到后建议多区多服)

b) 仅针对结构进行设计, 具体细节不过多深入(或者说都是可以被替换的)

c) 针对客户端短连接(区别在于有求才应,没有服务端主动下发消息. 技术上可以在此规则上视实际情况改为长连接)

d) 全区全服设计(变成多区多服会很容易,反之则不然;  多区多服实质就是对服务器组的整体横向扩展, 不过DB数据不再共享)

 

二. 详细说明,

索引:   a) Nginx

b) http

c) 平台处理服务器

d) GS 

e) DB,  Redis只读交互

f) 实时交互服务器

g) 回调类平台处理服务器

a) Nginx

通过Nginx反向代理, 接受客户端请求, 使得http 具有横向扩展性

b) http, 

利用 java 中的 jetty, netty 可以比较方便的实现

功能定位:(GameCenter)

1. 接收来自Nginx的消息

2. 登录状态的检测和维护

3. 消息转发到对应的GS上

负载均衡(登录时选择空闲的GS)

同一登录期间所有消息都定向到同一服务器

4. 中转平台处理服务器的消息;

5. 维护一个Redis的在线信息表(哪个玩家当前在哪台http上), 供回调类平台,信息定位使用. 以及防止重登陆(页游会出现,Nginx 仅根据IP分配)

c) 平台处理服务器,

作为Client端,连接http

单独独立出来的目的是方便灵活对接不同的平台

功能定位:

1. 与具体平台相连,处理和平台相关的逻辑(如登录等)

2. 玩家ID 的创建和分配也在这一块(将对应的平台ID转换为游戏内ID)

d) GS: GameServer,游戏服务器

作为Client端,连接http

功能定位:

1. 玩家角色数据中心. 角色数据的存储点(真正和角色数据库打交道的地方)

2. 单人逻辑(交互逻辑剥离出去).

单人逻辑比较单一清晰. 剥离掉交互逻辑后,变得最够简单,稳定性更好,也 不用担心多线程问题(因为不存在线程间交互数据的需要--所有玩家在这一层 次上都不产生交互)

3. 在需要的情况下,将消息请求转发到对应的实时交互服务器.

e) DB, Redis

这两者逻辑初步都直接写在GS上

DB, 满足玩家数据持久化的需求.且仅满足该需求,联合查询等复杂操作不提供(因为这是一个瓶颈点,尽量简化)

写的时候尽量模块化,方便在需要的时候独立出来成为单独的服务器(比如分库)

Redis, 提供只读类的交互, 比如排行榜,好友信息查询等

可按功能组织为多个

f) 实时交互服务器

按功能进一步会划分为 竞技场, PK 等....

这样的目的:

1. 将交互部分从GS上独立出来, 是的GS逻辑简单化

2. 根据游戏的具体功能不同可以决定要不要该部分, 如足够轻度, 仅只读交 互就可满足

3. 容易实现跨服务器交互,战场等

4. 横向扩展容易,比如多个竞技场服务器

g)回调类平台处理服务器

对应于处理主动由平台发起的操作, 比如支付发货等

通过由http维护的在线信息表定位玩家在哪台http上

实际实现时, 优先考虑直接完成回调处理,不联系http. 比如支付发货,直接往数据库写入发货订单,完成支付逻辑.