新一代游戏服务端框架，该是什么样的？

hzbooks

于 2021-10-29 08:00:00 发布

阅读量960

点赞数

文章标签：游戏大数据编程语言 java linux

原文链接：https://mp.weixin.qq.com/s?__biz=Mzg5MDU5NTM1NQ==&mid=2247527186&idx=1&sn=0d3b0d38f3359faae93b68ead3e84d74&chksm=cfd81a66f8af9370c5c32cc881916afb14550f14a239a6dfb8b0e4c3fdcee7bf8c94cf4466eb&scene=126&&sessionid=0

版权

本文探讨了游戏服务端框架从操作系统功能库到计算资源和游戏元素抽象模型的演变，并预测了下一代可能的发展方向：集群计算资源抽象和针对不同类型游戏的专门框架。作者罗培羽指出，随着集群操作系统的进步，未来的框架将更好地处理分布式计算，同时可能出现针对特定游戏类型的定制化框架，提高开发效率和性能。

摘要由CSDN通过智能技术生成

说起游戏服务端引擎，大家会想起Skynet、KbEngine、Photon、Pomelo等等。在探索服务端技术时候，我们不仅仅要了解当代服务端引擎，更要有些前沿眼光，去预测未来的游戏服务端是什么样的。因为只有把握了技术的发展趋势，才能在下一波潮流中立足，甚至成为引领者。

在此，华章计算机特别邀请《百万在线：大型游戏服务端开发》的作者罗培羽分享他对游戏服务端框架发展趋势的看法。

分享嘉宾罗培羽是广州四三九九公司的技术主管，拥有丰富的游戏开发经验。著作《Unity3D网络游戏实战》被多家高校选用作为教材，新作《百万在线》在上市两周后即登顶京东游戏类新书版TOP1，对等多个前沿领域都保持着持续的跟进。

第1代：操作系统功能库

要探索游戏服务端框架的未来，就要先探究游戏服务端框架的演进过程。在此，我从“功能抽象”的角度，将当前的游戏服务端分成层3个世代。

第1代服务端框架是对操作系统功能的封装，如果把网络库也当做框架的话，那么像muduo、libevent、pomelo可以称作第1世代的框架。他们的特点是基于某种语言，对操作系统所提供的功能做出封装，使它更容易使用。下页PPT展示的是linux下网络多路复用的一个接口epoll_ctl，它实则包含了6个设置项，使用起来很麻烦。第1代框架会对它做封装，使得易用一些。有些框架还会针对不同的平台，提供统一的接口，例如在linux下使用epoll、在windows使用IOCP，使得服务端可以运行在多种平台上。

第1代服务端仅仅是对操作系统功能的封装，它的抽象层次相对低，但对应的它更为通用。这类框架往往会提供网络模块、数据库模块、日志模块，封装一些常用功能，规定一套协议格式。如下图所示，框架（绿色部分）提供了一些基本功能，任何游戏相关功能都需要用户自己去实现。

第2代：计算资源抽象模型

Skynet是典型的第2代服务端框架，它的特点是将硬件资源做出一层抽象，使得更符合游戏内容的表达。线程算是操作系统对CPU资源的分割的最小单位，线程切换、新建线程的任有一定的性能开销，所以一台普通物理机一般只能同时支持数百个线程。Skynet模拟了Actor模型，它可以支持数千个Actor并发运行，某种程度上看是对计算资源的抽象。

通过资源抽象，Actor模型能够更好的表达游戏元素。例如要开发一款斗地主游戏，如果用一条操作系统线程来处理一张桌子的逻辑，那一台物理机只能支撑数百台桌子，也就是一两千个玩家同时在线。而如果每条线程处理多台桌子的逻辑，那每条线程将抽象成“桌子集合”，“桌子集合”是个妥协的概念，出于计算机性能考虑而强行划分的游戏元素。而如果使用Actor模型，可用一个Actor表示一台桌子，更接近原始的游戏元素。

第3代：游戏元素抽象模型

角色扮演、开房间战斗（部分射击游戏、竞技游戏……）等类型的游戏都具有“角色在场景中”的特点，服务端底层可以进一步抽象，把所有事物归结为实体和空间两大类。

下图PPT展示的是类BigWorld的架构，服务端划分成了Base、Ceil等不同类型的进程，Ceil是一种管理场景的进程，图中Ceil1包含森林、村落两个场景（空间），Ceil2包含沼泽场景；角色（实体）A和B在森林中。由于服务端多做了一层抽象，服务端框架便能够提供“角色行走”“切换场景”“感兴趣区域”“无缝大地图”的功能，方便开发者使用。

在同一个抽象层级上，不同框架选择不同的语言，不同的技术方案，有些性能较好、有些更容易使用，但它们能够提供的功能还算较为相似。下一代游戏服务端框架，一定会采用更进一层的抽象模型，在此，我认为会有两个方向，其一是对集群计算资源的抽象，其二是对不同类型游戏做进一步的抽象。

第4代1：集群操作系统上的框架

如今一般意义上的操作系统会将CPU、内存等概念做抽象，让用户不必关心程序代码是运行在哪个CPU核心上，也不必关心变量存储在内存中的哪个位置。而当前游戏的分布式系统，大多只是单机系统的叠加。

随着集群系统的演进，未来会出现针对集群的操作系统（当前K8S有此潜力），会抽象集群中的各种资源，让用户不必关心程序代码是跑在哪一台机器上，开发者能够灵活掌控整个集群。与之对应，会出现针对分布式集群的语言和编程模式。在集群基础上去构建的框架会与单机框架不同。

集群系统的一个难点是无法抹平机器间的差异。例如Skynet作者曾在博客中写到“任何抹平节点间差异的尝试都要谨慎”，因为集群间更容易出现网络中断、部分机器故障，不能把集群的通信类同于单机内的通信，此外，集群间的事务也受到了CAP理论的限制，往往需要根据需求在性能和可靠性之间权衡，没有放之四海而皆准的方案。

然而，无法抹平节点差异，这是当前的现实的问题，但它未必会是未来的问题。在单机中，L1储存和L2存储存的性能和可靠性也存在很大差异，初期开发者需要考虑这些差异才能编写性能优良的程序，而现在，开发者并不需要关心多级缓存的存在，操作系统和编译器会自动处理好各种寄存器调用，效率很也高。以此类推，未来我们也许可以找到一种合适的抽象模型，让集群程序与单机程序无差异运行。