当前我们游戏服务器的优化方案

现状

我们服务器的代码最早源于一套WOW的开源私服。本质上是单体架构。虽然拆分出了一个login进程，还有最近拆分出了一个dbmgr进程，游戏的主逻辑还是在一个单体的gameworld进程中。
一般ARPG游戏，按数据属性对功能进行划分，可以大致分为全局的world和场景scene。和场景，特别是和战斗相关的逻辑，对实时性要求最高；但这部分数据仅局限于area of interest(aoi)里。
场景数据一般应包括玩家的血量，魔法值，技能，场景状态等，对实时性要求最高。全局数据包括所有玩家账号相关的信息，所有公会，活动等，实时性可以打折。

优化方向

单体架构对于体量不大的游戏，在保证数据安全的情况下(如之前的拆分dbmgr进程)，开发效率比较高，不用涉及频繁的进程间RPC。那万一游戏火了呢？那就要再拆分。把原来的单体打散。

场景和非场景功能拆分

现在非场景功能在一个WorldRunnable线程里实现；场景功能由一个线程池里的工作者线程从场景列表里互斥的取出场景进行更新。首先可以简单一点处理：将gameworld进程拆分成world进程和scene进程。
这样做可以隔离场景功能和非场景功能，例如，不会因为某个场景玩家特别多而影响全服广播的发送。

进一步拆分场景进程

毫无疑问，场景上的计算是最耗CPU资源的。虽然现在一台服务器几十到上百个核心很正常，但场景功能集中在一个进程中，一个场景有问题有可能导致场景进程崩溃，这种设计会造成一个场景的BUG影响其他场景。也就是说在容灾上不够完美。当然，大公司的游戏才需要考虑这种问题。
通常，首先想到的方案是，开几个同样的场景进程，每个进程绑定不同的世界地图，指定的进程运行某类型的副本。我是不喜欢这种方式的，部署上比较麻烦，不够灵活。而且需要在策划方面有比较精准的安排，才能避免出现一些热点副本。所以，更灵活的方式应该是把哪个进程运行哪个场景作为配置信息集中放在某处，例如world进程，或者redis,etcd之类的中间件(可以少一点RPC，更好的解耦)。同时由world负责负载均衡。