游戏服务器首先必须是安全的,大型在线游戏理论上支持在线用户是无限的。我们无法一次性做到无限，但我们可以通过负载均衡做到高扩展性,高伸缩性，高可用以及支持高并发的游戏服务器。无论是游戏服务器架构还是web 服务器架构，如果前期设计不好,后边将面临着重构的风险。当然我们也要考虑以重构的方案。
无论什么服务器架构都是从0到1 再到无穷的。我们只要把基础架构做好,上线之后可以慢慢进行扩展,甚至于重构。
agent :代理服务器及登陆服务器,在该服务上进行维护用户登陆状态,以及作为其他服务器的转发。在上层可以加四层负载均衡(TCP负载均衡) ,通过这种方式实现在线用户数量的横向扩展。同时也处理通讯协议,与用户服务交互验证用户信息。
logic:逻辑服务器，主要包括有:活动,奖励,关卡,背包,交易,技能,好友等逻辑处理。
user:用户服务器, 用户安全验证,白名单,黑名单,登陆令牌生成，用户第三方账号绑定信息,用户角色信息,等处理。
BA:战斗服务器代理，代理各种战斗服务器。由agent 将消息转发过来，在经过进一步数据处理,转发至具体的战斗服务或者具体的战斗服务器组,同时也可以作分区分服以及合服合区。BA和B灵活搭配可实现跨服,跨区战斗。
B:战斗服务器/战斗服务组。用于处理针对性的战斗，也可以用于搭建高可用性的战斗服务器。
IM: 聊天室,单聊，群聊,广播.以及通知推送功能。
area: 选区服务,用户登陆完毕之后，显示区服列表,跨服跨区信息,区服维护状态。
dbproxy:db 代理服务器。代理cache 和db 在架构中缓解cache和db压力。
其他服务就不再一一叙述。
通讯协议:
包长 | 用户ID | token | 操作类型 | 请求序列号 | 客户端版本 | 消息内容 | md5 |
token由agent在线用户定时(登陆成功)请求user 服务器生成,并通过心跳发给client的。客户端拿到之后,放进通讯协议中。客户端版本:可以通过后台管理设置禁用,也可以通过版本号,作服务器重构兼容客户的版本(虽然这个很不爽)。最好的还是通讯协议做好兼容。
在服务架构内部采用rpc通讯。通过zk(zookeeper) 来作服务发现和服务集群。其中rpc 可分场景分别选取同步和异步方式。如用户登陆之后,采用异步rpc方式把用户的其他信息增加到cache.用户退出登陆时(客户端心跳失败之后)异步rpc 持久化用户数据。logic,user,BA,B,IM,area,dbproxy均为rpc和zk 实现内部通讯，都是zk上的一个节点。
跨区服/合区服。只有将area ,B,BA,agent,client,通讯协议等参与协同工作才可实现。如跨服，通过area(选区服务)在 client 上可跨服战斗的列表。client 获取列表之后,转换成我们制定的通讯协议发送给agent服务。在转发给BA，由BA 找到相应的跨服服务器B。如合服,如果服务分服配置一致，也可直接在BA处进行合服;如果是复杂的分服,可参考跨服流程。
