现在越来越多的游戏，像皇室战争一样，会做成全球同服，统一入口。这种方案带来的用户体验和以前的滚服游戏很不一样。这里就全球服的游戏谈谈架构设计。
首先，所谓的全球同服只是给玩家的感觉是只有一个服，而非真的只有一台服务器。否则像皇室战争这样火爆的游戏性能上是不可能扛得住的。一般底层做成分布式的结构，主要划分成：
- login：负责注册和登录，注册时通过负载均衡选到合适的game服，然后返回game服id并保存下来。以后登录固定等到创角的game服。它是个单点结构。
- gate：负责维持客户端的连接，以及转发消息。它是一个消息的中转站，无论是客户端和服务端之间，还是服务端与服务端之间的通信都会经过gate。gate是状态无关的，所以是多点。
- game：游戏的主要逻辑，包括单人和多人。每个游戏角色从属于一个game，与其他game之间是rpc通信，通过gate转发。game必然是多点。
- global：负责全局性的游戏逻辑。如活动的开启结束、匹配战斗对手等。这种全局一份的内存数据和逻辑适合放在global上。它是单点。
- db：数据库这块，一种做法是分布式，把db挂在每个服务器下面；另一种是集中式，通过一个专门的db server来管理，可以做成mysql集群。
- zookeeper：用于服务器管理，非常方便，可以获得所有服务器的overview，万一有服务器down掉也能及时知晓。
- redis：全局性数据的缓存，例如可以用来做多点服务器（如game）的负载均衡，策略可以基于每个服的创角数、在线数等等。
下面是一些常见系统的架构设计：
- 聊天：功能较独立，适合放在单独的聊天服务器上，聊天主要涉及到消息的转发和历史记录的内存存储，负载不大，一般不会成为瓶颈，做成单点即可。
- 好友：可以做成独立服务器，也可以做在game端，后者需考虑数据的双向存储问题。
- 排行榜：适合做成单独的排行榜服务器，启动时在内存中构建排行榜，数据更新时game向rank服同步。
- 匹配战斗：对于皇室战争、王者荣耀这种匹配战斗的游戏模式，可以在global上做调度，找寻到合适的match服，再将所需战斗数据同步过去进行战斗。
以上只涉及到架构划分，至于运维部署那就是另一个话题了，参见游戏风云：阿里云全球同服游戏方案全面解读。