[游戏]服务端的逻辑分服与物理分服

背景

工做室也经历过好几个游戏了。服务端的架构跟实际业务需求出现过很多的冲突。致使后来花了挺多时间去擦屁股的。以最近的一个游戏举例，本来的世界观设想是一个大服的世界观。也就是只有一个服，撑下百万用户，数万同时在线的设计。然后随着业务变化和线上表现，本来大服的设计并不能知足，最终变成了滚服玩法。因为大服变滚服，在原来的服务器架构约束下，对于后续增长的跨服玩法和合服实现都带来了比较大的麻烦和很多的工做量。

物理分服

原来的架构是按照大服设计的，因此在数据库上面的设计一个服对应一个数据库。假设咱们滚了500个服，就须要建500个数据库，部署500个游戏服。不管后续跨服、合服的业务扩展，仍是运维的维护方面，都变得比较复杂和困难。特别是合服的需求上面，须要将两个数据库甚至多个数据库合并成一个数据库。在量上来的时候，这一切都变得无比繁琐和复杂。开发人员也须要花费较多的人力和时间去写相应的工具。并且操做相对复杂，也比较容易出bug。并且后续新增的业务若是出现了持久化数据就须要增长相应的合服处理。

逻辑分服

若是说咱们一开始就已经将数据库合并了呢，是否是后续根本就不须要去合并数据库了。因此若是在当初框架设计的时候就已经按照逻辑来分服的话，后续的事情处理起来就简单多了。问过同行业的一些游戏架构，他们也是这么处理的。

对于合服

由于数据其实仍是在同一个库里面，并且也是在同一个服务器里面。只要简单处理，或者甚至不须要任何处理，就能够将两个或多个服合并。只须要在后台设置一下入口配置、可见配置就能够解决合服的问题了。

对于跨服

跨服本来的问题就是须要从不一样库读取数据和与不一样服进行交互。若是自己就不存在多服的问题，也不存在跨服的问题。

虽然逻辑分服能够比较完美解决合服的问题，可是对于跨服仍是须要单独处理。毕竟若是一个逻辑分服的服务器真的扛不住的时候，就会出现真的物理分服。对于跨服的需求来讲，可能都是须要跨的。

维护成本

相对于物理分服，逻辑分服能够极大地下降运维成本。数据库数量级能够极大减小，服务器数量也能够减小。对于备份、更新等运维操做都相对变得简单。甚至能够不依赖于运维工具，就能够简单地维护机器了。一台机器部署一个服(多个逻辑服)对比一台机器部署多个游戏服(一个逻辑服)，须要初始化的内存通常来讲会变小(不排除不同的状况)，机器的资源占用通常来讲会小不少。因此对物理机的利用效率能够提升不少。

用户数量级的问题

逻辑分服必然会出现性能瓶颈，不可避免地出现了物理分服、分库的状况。而对于合服来讲，合服自己就是发生在用户数量或者同时在线数量不足的状况下出现的。若是用户数量过大，基本上不太可能出现合服的需求。若是前期量级大，已经物理分服了。后期量级小了，其实从新叠回去也不是什么大的问题。只须要跟运营沟通好了，仍是能够使用逻辑分服的事情去解决合服的事情。固然若是运营须要真的在不一样物理服上面进行合服，我也没有想到比较好的办法，只能又苦逼地去处理的样子。

开发成本

因为逻辑分服，的确是增长了一些内容，譬如玩家所在的服务器ID。可是这个处理起来并无多大的难度，并且对key值也并无多大的影响。

逻辑分服的架构对于大世界和滚服都是支持的，只是对于大世界的话，就浪费了一个存储空间和一点点内存。可是这样的框架能够自如应对大世界到滚服之间的变化。若是一开始就按照大世界来设计，万一某一天滚服了，就要麻烦地多。

因此逻辑分服并不会提高多大的开发成本。