大服变滚服：工作室也经历过好几个游戏了

背景

工作室也经历了几场比赛。 服务器端架构与实际业务需求之间存在很多冲突。 结果我花了很多时间擦屁股。 以最近的一场比赛为例。 原本的世界观是大型服务器的世界观。 也就是说，只有一台服务器可以支持数百万用户、数万人同时在线。 然后随着业务和线上表现的变化，原来的大服务器设计并不理想，最终变成了滚服玩法。 由于从大服务器到全服上线的转变，在原有服务器架构的限制下，后续跨服玩法的增加以及服务器合并都带来了相当大的麻烦和大量的工作量。

实体服务

原来的架构是基于大型服务器来设计的，所以在数据库设计上，一台服务器对应一个数据库。 假设我们推出500台服务器，我们需要构建500个数据库，部署500个游戏服务器。 无论后续的跨服务器或合并服务器的业务扩展，还是运维的维护，都变得更加复杂和困难。 尤其是服务器合并需求，需要将两个数据库甚至多个数据库合并为一个数据库。 当涉及到数量时，一切都变得极其繁琐和复杂。 开发者还需要花费更多的人力和时间来编写相应的工具。 而且操作比较复杂，容易出错。 而且，如果后续新增业务出现持久化数据，还需要增加相应的服务器合并处理。

逻辑分配

如果我们从一开始就已经合并了数据库，那么后面就根本不需要合并数据库了。 所以，如果当初设计框架的时候就已经按照逻辑划分了服务器，那么后续的事情处理起来就会简单很多。 我问了一些同行业的游戏架构，他们也是这样处理的。

用于服务器合并

因为数据其实还在同一个库里，而且也在同一个服务器里。 可以合并两个或多个服务器，只需很少的处理或根本不需要处理。 只需要在后台设置入口配置和可见配置即可解决服务器合并问题。

对于跨服务器

跨服务器最初的问题是需要从不同的库读取数据并与不同的服务器进行交互。 如果本身不存在多服务器问题，那么也不存在跨服务器问题。

虽然逻辑服务器划分可以完美解决服务器合并问题，但跨服务器仍然需要单独处理。 毕竟，如果逻辑上分布式的服务器确实无法应付，那么真正的物理服务器就会出现。 对于跨服务器的需求，可能需要跨。

维护费用

与物理服务器分布相比，逻辑服务器分布可以大大降低运维成本。 数据库大小可以大大减少，服务器数量也可以大大减少。 备份、更新等运维操作比较简单。 您甚至可以不依赖操作和维护工具来简单地维护机器。 在一台机器上部署一台服务器（多台逻辑服务器）相比在一台机器上部署多台游戏服务器（一台逻辑服务器）时，需要初始化的内存一般会更小（不排除不同情况），而且资源占用也小。机器的消耗会更小。 一般来说它会小很多。 因此，物理机的利用效率可以提高很多。

用户级别问题

逻辑服务器分布必然会出现性能瓶颈，物理服务器分布、数据库分布也必然出现性能瓶颈。 对于服务器合并，当用户数或同时在线用户数不足时，服务器合并本身就会发生。 如果用户数量过多，基本上不太可能需要合并服务器。 如果前期量级很大的话，在物理上就已经被击败了。 到了后期，幅度就变小了，再次叠加起来其实问题不大。 只要与运营沟通，仍然可以使用逻辑服务器划分来解决服务器合并问题。 当然，如果操作需要合并不同物理服务器上的服务器，我还没有想到更好的办法，所以只能苦苦应对。

开发成本

由于服务器的逻辑划分，确实增加了一些内容，比如玩家所在的服务器ID。 但这并不是很难处理，并且对键值没有太大影响。

逻辑服务器架构支持大世界和滚动服务器。 然而，对于大世界来说，它浪费了存储空间和一点点内存。 但这样的框架可以轻松应对从大世界到滚动服务器的变化。 如果一开始就按照大世界来设计的话，万一有一天翻车了，那就麻烦了。

因此，逻辑服务器分布不会增加太多的开发成本。