类似coc这种全球同服，并且注册玩家与在线玩家庞大的游戏，服务器端架构该如何设计呢？

刚好做过几款类似的全球唯一服的服务器，就简单谈谈，不好莫怪。

首先， 游戏服务器是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架构设计的，可以满足你的要求。

可以看我的博客： 手游服务器开发技术详解