背景
工作室也经历过好几个游戏了。服务端的架构跟实际业务需求出现过不少的冲突。导致后来花了挺多时间去擦屁股的。以最近的一个游戏举例，原本的世界观设想是一个大服的世界观。也就是只有一个服，撑下百万用户，数万同时在线的设计。而后随着业务变化和线上表现，原本大服的设计并不能满足，最终变成了滚服玩法。由于大服变滚服，在原来的服务器架构约束下，对于后续增加的跨服玩法和合服实现都带来了比较大的麻烦和不少的工作量。
物理分服
原来的架构是按照大服设计的，所以在数据库上面的设计一个服对应一个数据库。假设我们滚了500个服，就需要建500个数据库，部署500个游戏服。无论后续跨服、合服的业务扩展，还是运维的维护方面，都变得比较复杂和困难。特别是合服的需求上面，需要将两个数据库甚至多个数据库合并成一个数据库。在量上来的时候，这一切都变得无比繁琐和复杂。开发人员也需要花费较多的人力和时间去写相应的工具。而且操作相对复杂，也比较容易出bug。而且后续新增的业务如果出现了持久化数据就需要增加相应的合服处理。
逻辑分服
如果说我们一开始就已经将数据库合并了呢，是不是后续根本就不需要去合并数据库了。所以如果在当初框架设计的时候就已经按照逻辑来分服的话，后续的事情处理起来就简单多了。问过同行业的一些游戏架构，他们也是这么处理的。
对于合服
因为数据其实还是在同一个库里面，而且也是在同一个服务器里面。只要简单处理，或者甚至不需要任何处理，就可以将两个或多个服合并。只需要在后台设置一下入口配置、可见配置就可以解决合服的问题了。
对于跨服
跨服原本的问题就是需要从不同库读取数据和与不同服进行交互。如果本身就不存在多服的问题，也不存在跨服的问题。
虽然逻辑分服可以比较完美解决合服的问题，但是对于跨服还是需要单独处理。毕竟如果一个逻辑分服的服务器真的扛不住的时候，就会出现真的物理分服。对于跨服的需求来说，可能都是需要跨的。
维护成本
相对于物理分服，逻辑分服可以极大地降低运维成本。数据库数量级可以极大减少，服务器数量也可以减少。对于备份、更新等运维操作都相对变得简单。甚至可以不依赖于运维工具，就可以简单地维护机器了。一台机器部署一个服(多个逻辑服)对比一台机器部署多个游戏服(一个逻辑服)，需要初始化的内存一般来说会变小(不排除不一样的情况)，机器的资源占用一般来说会小很多。所以对物理机的利用效率可以提高很多。
用户数量级的问题
逻辑分服必然会出现性能瓶颈，不可避免地出现了物理分服、分库的情况。而对于合服来说，合服本身就是发生在用户数量或者同时在线数量不足的情况下出现的。如果用户数量过大，基本上不太可能出现合服的需求。如果前期量级大，已经物理分服了。后期量级小了，其实重新叠回去也不是什么大的问题。只需要跟运营沟通好了，还是可以使用逻辑分服的事情去解决合服的事情。当然如果运营需要真的在不同物理服上面进行合服，我也没有想到比较好的办法，只能又苦逼地去处理的样子。
开发成本
由于逻辑分服，的确是增加了一些内容，譬如玩家所在的服务器ID。但是这个处理起来并没有多大的难度，而且对key值也并没有多大的影响。
逻辑分服的架构对于大世界和滚服都是支持的，只是对于大世界的话，就浪费了一个存储空间和一点点内存。但是这样的框架可以自如应对大世界到滚服之间的变化。如果一开始就按照大世界来设计，万一某一天滚服了，就要麻烦地多。
所以逻辑分服并不会提升多大的开发成本。