因为是本着提升架构能力为出发点，所以不考虑，skynet，各种像阿里云，腾讯云之类的现成解决方案
添加评论
分享
我们也做了几款类似的游戏，分享下。
【架构】
1、login/gate。所有client连接都首先连接到这里，登陆认证后，给client分配一个game节点ip和port。
2、game。真正的游戏业务服，login会通过玩家信息做个分发，把玩家分发到指定的game，client通过返回的ip和port直连到指定game，并断开和login的链接。
3、world。大世界管理服，作用是管理game，以及进行game之间的消息分发。
4、cache。一些公用的数据会通过键值区分开放到缓存中，比如排行榜这类。可使用redis实现，可以作为全局的，也就是所有game节点都可访问。
5、db。可以使用一些中间件做mysql集群。但推荐使用mongodb 的 sharding，很好用，尤其是3.2版本后使用wiredtigger引擎，性能好而且使用方便。
【依赖关系】
1、login作为game的master要先启动，且game启动后要注册到login。也就是login持有可用的game的列表。
2、world也作为game的master。game也需要注册到world，方便world进行分发。
3、db如果使用mongodb，可以直接使用它的cluster集群，可以做master-slave高可用以及shard集群。
4、cache如果使用redis也可以使用做HA高可用和cluster集群。
【热点】
1、大并发链接的时候login可能会是热点，不过没关系。可以坐下lvs或者nginx的loadbalance分流即可。
2、cache。因为是全局的，可以如上说做ha和sharding。
3、db。如上所述做ha和sharding。
【利器】
1、可以使用zookeeper坐下game的集群管理。
2、可以使用dubbo坐下rpc服务治理。
先写到这里，大概就是这样。
【架构】
1、login/gate。所有client连接都首先连接到这里，登陆认证后，给client分配一个game节点ip和port。
2、game。真正的游戏业务服，login会通过玩家信息做个分发，把玩家分发到指定的game，client通过返回的ip和port直连到指定game，并断开和login的链接。
3、world。大世界管理服，作用是管理game，以及进行game之间的消息分发。
4、cache。一些公用的数据会通过键值区分开放到缓存中，比如排行榜这类。可使用redis实现，可以作为全局的，也就是所有game节点都可访问。
5、db。可以使用一些中间件做mysql集群。但推荐使用mongodb 的 sharding，很好用，尤其是3.2版本后使用wiredtigger引擎，性能好而且使用方便。
【依赖关系】
1、login作为game的master要先启动，且game启动后要注册到login。也就是login持有可用的game的列表。
2、world也作为game的master。game也需要注册到world，方便world进行分发。
3、db如果使用mongodb，可以直接使用它的cluster集群，可以做master-slave高可用以及shard集群。
4、cache如果使用redis也可以使用做HA高可用和cluster集群。
【热点】
1、大并发链接的时候login可能会是热点，不过没关系。可以坐下lvs或者nginx的loadbalance分流即可。
2、cache。因为是全局的，可以如上说做ha和sharding。
3、db。如上所述做ha和sharding。
【利器】
1、可以使用zookeeper坐下game的集群管理。
2、可以使用dubbo坐下rpc服务治理。
先写到这里，大概就是这样。
更多回答
马剑飞 一只垃圾程序猿
刚好做过几款类似的全球唯一服的服务器，就简单谈谈，不好莫怪。
首先， 游戏服务器是IO密集型服务器，它的主要瓶颈在网络IO，而不是CPU，这点要记住了。所以经常服务器问题都会出现在网络IO，带宽，数据库磁盘读写上面，而非CPU上面。
其实全球同服也就是大量在线嘛，比如C1000k，甚至更多。同服，只是你看起来同服，而不是他本身就在同一个服务器上，或者同一个进程上，这是完全不现实的。一个好的服务器进程，能同时承载10k的游戏玩家(还依赖于游戏逻辑复杂度)已经不错了。其实要全球同服，就是堆服务器进程嘛。
讲一下我用过的其中一种架构模型，也是公司按着bigworld架构设计的：
1.Gate:首先要有一个(多个)Gate(网关)服务器，负责客户端连接及消息转发到GameServer(游戏服)（选服逻辑）,保持客户端到服务端的连接
没有任何逻辑，只做消息加密和解密，以及客户端和服务器消息的转发(相当于两者之间的桥梁).
2.GameServer:GameServer是主要的游戏进程,提供游戏逻辑功能(采用单进程(或者单线程)模型,游戏服务器的瓶颈从来不在CPU,所以只做逻辑功能的话单线程足够了,在这里没必要用多线程或多进程)。
3.DBManager:实现数据库的读写，方便Game服务器异步读写数据库的数据(有些把数据库读写放在游戏服，没有单独的服务器，那恐怕游戏服单进程就不够用了)。
4.GameManager:负责管理所有的GameServer，GameServer之间消息转发，提供广播到所有Game的功能。
客户端连Gate，Gate连GameServer，GameServer连DBManager，GameManager管理所有的GameServer并通知所有的Gate。
除了GameManager只有一个，理论上Gate，GameServer，DBManager都可以扩展到多个实例，你要实现全球唯一服，理论上就是扩展GameServer，那么怎么让他们看起来在一个服呢？其实很简单，COC大多数都是单服玩法，只有交互玩法的时候你才能感受到它是同一个服。
主要讲讲GameServer，这是主要的处理服务器逻辑的地方，一般单进程就可以了，一个epoll_wait
hold住全场，然后做分发，理论上cpu都能承载的住，而epoll能处理的上限，一般跟机器的内存有关，远大于1024，正常的也达到100k，当然考虑到逻辑的复杂度，一个实例一般处理的连接接近10k就可以了。
那怎么处理100k，1000k甚至更多了，那就多个实例，那这样还是唯一服吗？是的，至少可以看起来是，游戏自然有单人玩法和多人玩法，单人玩法自然自己在自己的服就可以了，谁也不知道是不是跟别人一个服。
当然有全服的排行榜，好友系统之类的怎么办呢，其实很简单，我们不是有GameManager吗，它就是负责做这事的，每当你发个好友请求，GameManager广播一条消息，然后如果有某个GameServer存在这个玩家，那就回应你，你们就可以相互通信了，更简单的想办法获取玩家的服务器ID号，直接通过GameManager转发给那个服务器，自然就可以通信了，就像在同一个服务器一样。
排行榜呢，最简单的，指定一个服务器，或者单独开辟一个服务器做排行榜，所有数据变动都通知这个服务器，然后服务器自然就能排行了，然后再广播。
双人战斗或者多人副本呢？
像COC这样的，掠夺战，我们当时的做法就是，直接搜到敌方，然后把自己的玩家，士兵军队等需要的数据序列化之后，传到对面的服务器去，反序列化，然后直接开打，打完再把数据传回来。
更多人的呢，那就方便点，再开辟一类服务器，叫BattleServer，专门负责多人玩法，副本玩法之类的，多人的时候，把所有的多人数据迁移到BattleServer，然后多人（副本玩法）结束的时候，再通过GameManager把数据迁移回原来的服务器。
这样看，其实全球唯一服也就没有那么高大上了。
如果有兴趣，可以看看KBEngine服务器引擎，作者按照bigworld架构设计的，可以满足你的要求。
可以看我的博客： 手游服务器开发技术详解
首先， 游戏服务器是IO密集型服务器，它的主要瓶颈在网络IO，而不是CPU，这点要记住了。所以经常服务器问题都会出现在网络IO，带宽，数据库磁盘读写上面，而非CPU上面。
其实全球同服也就是大量在线嘛，比如C1000k，甚至更多。同服，只是你看起来同服，而不是他本身就在同一个服务器上，或者同一个进程上，这是完全不现实的。一个好的服务器进程，能同时承载10k的游戏玩家(还依赖于游戏逻辑复杂度)已经不错了。其实要全球同服，就是堆服务器进程嘛。
讲一下我用过的其中一种架构模型，也是公司按着bigworld架构设计的：
1.Gate:首先要有一个(多个)Gate(网关)服务器，负责客户端连接及消息转发到GameServer(游戏服)（选服逻辑）,保持客户端到服务端的连接
没有任何逻辑，只做消息加密和解密，以及客户端和服务器消息的转发(相当于两者之间的桥梁).
2.GameServer:GameServer是主要的游戏进程,提供游戏逻辑功能(采用单进程(或者单线程)模型,游戏服务器的瓶颈从来不在CPU,所以只做逻辑功能的话单线程足够了,在这里没必要用多线程或多进程)。
3.DBManager:实现数据库的读写，方便Game服务器异步读写数据库的数据(有些把数据库读写放在游戏服，没有单独的服务器，那恐怕游戏服单进程就不够用了)。
4.GameManager:负责管理所有的GameServer，GameServer之间消息转发，提供广播到所有Game的功能。
客户端连Gate，Gate连GameServer，GameServer连DBManager，GameManager管理所有的GameServer并通知所有的Gate。
除了GameManager只有一个，理论上Gate，GameServer，DBManager都可以扩展到多个实例，你要实现全球唯一服，理论上就是扩展GameServer，那么怎么让他们看起来在一个服呢？其实很简单，COC大多数都是单服玩法，只有交互玩法的时候你才能感受到它是同一个服。
主要讲讲GameServer，这是主要的处理服务器逻辑的地方，一般单进程就可以了，一个epoll_wait
hold住全场，然后做分发，理论上cpu都能承载的住，而epoll能处理的上限，一般跟机器的内存有关，远大于1024，正常的也达到100k，当然考虑到逻辑的复杂度，一个实例一般处理的连接接近10k就可以了。
那怎么处理100k，1000k甚至更多了，那就多个实例，那这样还是唯一服吗？是的，至少可以看起来是，游戏自然有单人玩法和多人玩法，单人玩法自然自己在自己的服就可以了，谁也不知道是不是跟别人一个服。
当然有全服的排行榜，好友系统之类的怎么办呢，其实很简单，我们不是有GameManager吗，它就是负责做这事的，每当你发个好友请求，GameManager广播一条消息，然后如果有某个GameServer存在这个玩家，那就回应你，你们就可以相互通信了，更简单的想办法获取玩家的服务器ID号，直接通过GameManager转发给那个服务器，自然就可以通信了，就像在同一个服务器一样。
排行榜呢，最简单的，指定一个服务器，或者单独开辟一个服务器做排行榜，所有数据变动都通知这个服务器，然后服务器自然就能排行了，然后再广播。
双人战斗或者多人副本呢？
像COC这样的，掠夺战，我们当时的做法就是，直接搜到敌方，然后把自己的玩家，士兵军队等需要的数据序列化之后，传到对面的服务器去，反序列化，然后直接开打，打完再把数据传回来。
更多人的呢，那就方便点，再开辟一类服务器，叫BattleServer，专门负责多人玩法，副本玩法之类的，多人的时候，把所有的多人数据迁移到BattleServer，然后多人（副本玩法）结束的时候，再通过GameManager把数据迁移回原来的服务器。
这样看，其实全球唯一服也就没有那么高大上了。
如果有兴趣，可以看看KBEngine服务器引擎，作者按照bigworld架构设计的，可以满足你的要求。
可以看我的博客： 手游服务器开发技术详解