游戏服务端的内部结构分析和逻辑分析和物理分布

admin

游戏服务端的内部结构分析和逻辑分析和物理分布

工作室也经历了好几次游戏服务端的开发。游戏服务端体系结构和实际业务需求之间存在许多冲突。擦屁股花了我很多时间。以最近的一场比赛为例，最初的世界观被认为是一种精心打扮的世界观。换句话说，只有一种套装可以同时支持数百万用户和数万用户。此后，随着业务和在线表演的变化，原来设计的大套服不能满足，最终成为了套打的方法。由于将大型服装改为卷装，在原有游戏服务端架构的约束下，为后续增加跨服播放和实现组合服装带来了更多的麻烦和大量的工作量。
游戏游戏服务端的逻辑服务和物理服务
物资调运
最初的架构是根据大套装设计的，因此数据库上的设计对应于一套套装。假设我们推出500套套装，我们需要建立500个数据库并部署500套游戏套装。无论是后续的跨服务和跨服务业务扩展，还是运营维护，都变得更加复杂和困难。特别是，对于服务集成的需求，需要将两个甚至更多的数据库合并到一个数据库中。说到数量，所有这些都变得极其复杂。开发人员还需要花费更多的人力和时间来编写相应的工具。此外，操作相对复杂，更容易出现错误。此外，如果持久数据出现在后续新添加的服务中，则需要添加相应的组合服务处理。
逻辑分布
如果我们从一开始就合并了数据库，这是否意味着将来没有必要合并数据库？因此，如果最初的框架设计已经按照逻辑进行了划分，后续的事情将更容易处理。当被问及同行关于这个行业的一些游戏结构时，他们也这么做了。
对于组合服装
因为数据仍然在同一个库中，但也在同一个游戏服务端中。只要有简单的处理或者甚至不需要任何处理，两个或更多的套装可以组合。只需在后台设置入口配置和可见配置，解决统一服务的问题。
对于跨服
交叉服务的最初问题是从不同的库读取数据并与不同的服务交互。如果没有多种服务的问题，就没有交叉服务的问题。
虽然逻辑服务划分可以很好地解决服务组合的问题，但是对于跨服务仍然需要单独处理。毕竟，如果一个逻辑游戏服务端不能真正处理它，就会有一个真正的物理游戏服务端。对于跨服务要求，可能需要跨服务。
维修费用
与物理分布相比，逻辑分布可以大大降低运行和维护成本。数据库和游戏服务端的数量可以大大减少。备份和更新等操作相对简单。即使不依赖操作和维护工具，机器也可以简单地维护。当一台机器部署一套(多个逻辑套装)时，与一台机器部署多个游戏套装(一个逻辑套装)相比，需要初始化的内存通常会变小(不排除不同的情况)，并且机器的资源占用通常会小得多。因此，可以大大提高物理机器的利用效率。
用户数量
服务的逻辑分布将不可避免地导致性能瓶颈，服务和库的物理分布也不可避免地发生。对于组合服务，当用户数量或在线数量不足时，就会出现组合服务本身。如果用户数量太大，基本上不可能满足对服装的需求。如果早期阶段的规模很大，它已经在物理上被分割了。后期的数量级很小，但折叠起来并不是什么大问题。只需要与运营很好地通信，还可以用逻辑来划分服务来解决服务。当然，如果运营真的需要组合在不同的物理衣服上，我没有想到更好的方法，但是我必须用同样的困难来处理它。
开发成本
由于逻辑分布，添加了一些内容，如播放器的游戏服务端标识。然而，处理这一点并不是很困难，并且它对关键值没有太大的影响。
逻辑分发服务的体系结构支持大世界和滚动服务，但是对于大世界来说，它浪费了一点存储空间