Wind分布式游戏服务器引擎的实现

Doris232 · 发表于 2022-5-14 16:39

Wind是一款面向云的高性能、高效率以及高扩展性的大型分布式游戏服务器引擎。Wind利用Python语言的简洁语法以及丰富的生态库来提高游戏业务的开发效率，针对一些对性能有要求的游戏业务功能(如实时战斗功能)，Wind利用Golang的高并发特性来保证服务的高性能，同时Wind接入云的组件来保证游戏服务的动态扩展性，提高服务资源的利用率。

https://github.com/ferris1/wind

Wind是游戏服务器界首次结合go与python优点的服务器，如果Wind能解决你的问题的话，希望能帮Wind点个Star，如果不能解决大家的问题的话，也欢迎大家提Issue和Request，我会持续开发和完善Wind。
本文是Wind服务器引擎设计与实现系列的第一篇

1：Wind单服务引擎功能的设计与实现

2：Wind分布式集群功能的设计与实现(待更新)

3：Wind服务云部署功能的设计与实现(待更新)

Wind单机引擎功能的设计与实现

本篇文章主要介绍Wind的出现背景，Wind要解决什么问题，以及Wind的设计和服务器引擎实现方案。从游戏业务需求出发，介绍Wind拥有的特性以及引擎各个功能如何实现这些特性。
Wind出现背景

得益于云计算的低成本、按需灵活配置和高资源利用率的特性，大量的互联网应用已经在云上部署。但游戏服务上云的进度却很缓慢，这其中的原因跟游戏产品特性有关系。相对于互联网产品，游戏产品对延时更敏感，尤其是一些强竞技性游戏，如果将游戏服务部署上云的话，会有一些额外运算与路由导致延时增加，这也导致游戏服务上云进程比较缓慢。

虽然一些强竞技性游戏上云后可能影响游戏体验，但是对于一些休闲类、放置类、弱竞技类游戏来说，这些游戏对时延并不敏感，还是非常适合上云的。而且随着云游戏的发展和游戏产品的国际化，游戏上云是一个必然趋势。游戏上云可以很好运用云上资源，更灵活的配置服务资源以及更高效的管理服务，降低游戏服务的成本。

早前开源服务器更多关注的是单服务器内部的设计，如云风的Skynet，虽然单服务器性能很高，但没有提供一个很好的服务集群化方案，集群的配置、集群的监控管理以及集群间的通信交互都很麻烦，集群服务的动态扩展性也不强，导致搭建服务集群困难以及整体服务资源利用率低下。

因此Wind致力于解决上述问题，简化游戏服务集群方案，提高服务资源利用率，同时也保证游戏服务的开发效率以及运行性能。Wind是一款面向云的高性能、高效率以及高扩展性的大型分布式游戏服务器引擎。Wind利用Python语言的简洁语法以及丰富的生态库来提高游戏业务的开发效率，针对一些对性能有要求的游戏业务功能(如实时战斗功能)，Wind利用Golang的高并发特性来保证服务的高性能，同时Wind接入云的组件来保证游戏服务动态扩展性，提高服务资源的利用率。

游戏界有Unity和Unreal这样完善并且开箱即用的客户端引擎，这样的引擎大大缩短了游戏的开发周期，基本上一天就能做一个能跑的游戏。但是却并不存在一款大家熟知分布式服务器引擎，这样的服务器引擎可以快速上手并且能满足游戏各个阶段的开发需求。Wind致力于做一款易上手且完善的分布式服务器引擎，帮助独立游戏开发者或者中小企业快速搭建服务器框架并且快速开发游戏业务，降低游戏服务器开发难度与成本。

WindLogo.png

Wind引擎实现

大型分布式服务器主要由早前单服务引擎发展而来，早前服务器服务玩家数量较少，基本上单进程服务器便能服务玩家。但由于互联网技术的发展，玩家越来越多，单进程服务器服务不了更多的玩家，因此发展分布式服务器来服务更多的玩家。得益于云的发展，游戏服务上云提高了资源利用率，降低了服务维护成本。Wind分布式引擎主要由这三个部分组成，第一部分是单服务器引擎，第二部分是分布式集群，第三部分是服务云部署。

单服务引擎：

单服务引擎包含一个服务器能运转的所有功能，游戏客户端发送请求给单服务引擎，单服务引擎处理请求后并回包给客户端。单服务器引擎主要包括程序语言、网络通信、并发模型、远程函数调用这些主要功能。

分布式集群：

分布式集群由每个运行的单服务引擎组成，分布式集群主要是为了解决单服务器引擎只能服务少量玩家的问题，通过横向扩展服务器来解决单服务器压力过大的问题，分布式集群功能主要包含服务发现、负载均衡、消息队列和数据存储等功能。

服务云部署：

对于一些只有几十个人的游戏，你可能就只需要起一个服务就行了，但是对于上百万玩家的游戏，这时就需要起上千或者上万个服，而且针对不同地区有不同的部署方案，面对这么庞大的部署，如果纯手动管理，那会非常耗时耗力，这时就需要一些云部署工具来支持。云部署主要包含容器部署、K8S编排、服务治理与监控。
单服务器引擎

单服务引擎包含一个服务器运行的所有功能，能单独运行并服务一部分玩家。单服务引擎运行后，客户端通过网络通信将请求发送到服务器中，服务器通过并发模型将请求交给逻辑模块处理，逻辑模块通过序列化解码参数数据并将请求数据交给服务注册的RPC函数处理。
程序语言

目前游戏服务器开发语言使用比较广泛的组合是C/C++和Lua。C/C++属于静态语言，拥有很高的运行性能，但因为C/C++语法更倾向于计算机的理解方式，对程序员编写业务逻辑并不够友好，降低了产品的开发效率，而且C/C++热更方法比较有限，线上出问题时不能快速且方便的修复，可能要时不时的停服关机修复，比较影响游戏体验，因此引入语法更简洁、更方便而且支持打补丁的高级动态解释语言Lua。引入Lua后，C/C++的分工有了变化，一些要求高性能的服务器模块用C/C++编写，比如网络库、数学计算库以及局内实时战斗逻辑等，Lua负责一些对性能要求不高的模块，但业务逻辑量比较大的模块，这样的模块其实占游戏业务的很大一部分，比如游戏的一些外围系统：等级系统，背包系统，聊天系统等等。相比于Lua，其实个人更喜欢Python，Python比Lua拥有更简洁的语法、更高的容错以及更完善的函数库，在开发产品业务时，拥有更高的开发效率，所以Wind的游戏业务逻辑语言使用Python开发。

使用C/C++编写一些模块，可以很好解决服务运行效率问题，但C/C++没有自动内存管理，写逻辑时很容易发生内存泄漏，而且C/C++语法复杂，程序员上手难度较高，开发成本大，因此引入Golang语言。Golang以高并发著称，拥有比C++更简明的语法特性，可提升开发效率，同时Golang提供自动内存管理机制，极大的简化了程序员开发的难度。因此Wind使用Golang来开发一些对效率有要求的模块，目前Wind的网络库是Golang写的。一些对性能要求高的游戏业务你也可以使用Golang来开发，比如战斗功能。
Python与Golang的交互

Wind的网络库由Golang编写，目前支持TCP，之后会支持KCP、Udp和Quic这些协议。每个客户端连接过来后，Golang会开一个线程去处理网络数据，有数据发过来后，Golang会将数据交给Python逻辑端处理，这里有个问题，就是Python线程和Golang线程是怎么进行交互的？Wind服务器引擎的主线程是在Python端，在起服务器时加载Golang编写的网络动态库(so文件或者DLL文件)并且开启网络线程处理客户端数据，目前Python与Golang的数据交互使用Socket通信交互，Python端启用一个TCP端口，Golang连接这个端口并且将数据传送给Python端。当然你也可以换Python与Golang的交互方式，比如换成ZMQ的zmq_inproc通信，使用zmq_inproc通信时，线程间共享一个ZMQ Context，可以通过共享内存来传递数据，不需要使用I/O线程，可以加快Python和Golang的交互。

GoToPython.png

并发模型

游戏客户端所做的工作基本上是将数据按一定逻辑显示在屏幕上，单个客户端并不需要与太多的服务器进行交互，多的也就两三个左右，所以客户端基本上对并发没有太多的要求。但是服务器就不一样了，同一个服务器要服务的客户端可能是上千个，甚至可能是上万个，这时候就需要并发模型来合理分配服务器的计算资源并正确的为客户端服务。

为了最大化利用物理机的多核资源，一般会有两种并发模型，一种是单进程多线程模型，这种模型通常是单个进程中存在多个游戏服务，每个服务分配一个核进行计算。游戏界应用这种并发模型比较成熟的是云风的Skynet，Skynet启用多个工作线程来处理服务的事件，各个线程间基于消息传递来通信。这种单进程多服务的缺点是，服务之间的隔离比较弱，服务之间共用了进程的数据，单个服务发生问题时可能影响其他服务，这样的设计也并不适合云部署，云部署所满足的一个基本要求就是服务间相互独立，每个服务是云调度的基本单位，每个服务可自由的被调度，因此更适合云部署的是多进程单线程模型，每个进程是一个服务，同一台机器可以起多个进程来利用多核优势，同时单线程中使用异步来处理数据I/O，提高服务器的并发。

那么Wind使用的是哪个模型了？ Wind使用是的混合模型，Wind是单进程单服务，网络库利用Golang的高并发特性，每个客户端连接启用一个线程来读取数据，同时为了减低业务逻辑编写难度，避免多线程锁问题，Python使用单线程异步协程来编写业务逻辑。网络层的多线程消息数据会通过一个队列来发给Python协程(asyncio)。

bingfa.png

Python协程

Python协程本质上是异步，只不过这个协程是语言层面上的支持，编写游戏业务时更清晰、更简单。Python启动线程时，会启动一个事件循环，这个循环会一直检测是否有事件可以处理，如果某个任务要进行I/O(磁盘I/O或者网络I/O)，那么这个任务会被挂起，直到对应数据到来时，这个任务又会被事件循环处理。
import asyncioasync def main(): print('Hello ...') await asyncio.sleep(1) print('... World!')loop = asyncio.get_event_loop()loop.create_task(main())loop.run_forever()
使用异步协程编写游戏业务逻辑时，同一个时刻只能有一个客户端请求被处理，降低了开发难度，与协程搭配使用的是各个模块的单例化。
网络通信

实现游戏服务器时，主要会接触到的是传输层以上的一些网络协议，传输层协议包括UDP协议和TCP协议。UDP是一种无连接的协议，没有可靠性保证、顺序保证以及流量控制，但正是因为控制项比较少，UDP在数据传输过程中延迟小，速率高。游戏中一些对可靠性要求不高，但要求高速率的业务可以使用UDP传输，比如游戏语音服务。

TCP是面向连接的、可靠的、基于字节流的传输层通信协议，TCP通过序号确认机制、超时重传机制、重复累计确认机制和检验和机制来实现可靠性传输，同时提供流量控制和拥塞控制来控制源端的发送速率，以确保对端能正确接收。相对于UDP啥都没做来说，TCP什么事都做了，导致TCP传输速率低，延迟大。游戏是实时性应用，游戏的一些外围功能(背包功能、个人信息)时延要求不高，TCP够用了，但是对于游戏战斗这类高实时性功能，TCP的延迟太大了，会导致游戏战斗时体验会非常差。

为了解决TCP传输延时大的问题，游戏界通常会在UDP之上实现一个延时更低的可靠性传输协议，比如KCP，Enet。KCP能以比TCP浪费10%-20%的带宽的代价、换取平均延迟降低30%-40%，且最大延迟降低三倍的传输效果。ENet是专门为多人第一人称射击游戏Cube开发的可靠性传输协议，Enet提供连接管理，Enet最大的特点是提供多通道机制，每个通道包传送独立，单个通道会确保前一个序号消息到达才会发送下一个序号消息，以保证可靠性。

通常游戏会集成好几个传输协议到网络层，以便在不同需求场景下切换，比如集成UDP、KCP和TCP到网络传输层。Wind的网络层也会集成多个网络协议，以便在不同游戏场景中进行切换。

Wnet.png

远程函数调用(RPC)

在单机游戏中，如果你要实现某个游戏效果，你可以通过函数名字直接调用对应函数来实现效果，但在网络游戏中，有些游戏效果需要向远端的服务器请求计算或者数据(比如匹配，背包)来实现，这时就会需要远程函数调用。远程函数调用通常发生在同一个共享网络下的不同地址空间中，比如不同物理机。远程函数调用通常采用Request-Response通信模式，每个远程函数名字以Request/Response(也可以用其他结尾，比如Packet)结尾，以此来区分本地函数。

封装好远程函数调用库后，写代码时就像写本地函数调用一样，程序员并不需要关心与远端的交互细节。但与本地函数调用不同的是，远程函数调用需要经过网络传输，网络传输增加了调用的时延与不确定性，为了防止主线程逻辑卡死，远程函数调用一般设计成异步调用，Request包发出后，不会等待包的返回，而是Response包返回后在处理之前的逻辑。

实现远程函数调用需要两个功能支持，一个是序列化功能，一个是协议工厂功能。
序列化

序列化是一个将数据结构和对象信息转化成可以存储和传输形式的过程。我们在写代码时通常以对象的形式读取数据，因为对象更符合人类思维习惯，我们能更快编写程序代码。但是对象信息数据通常是不连续的内存，不能直接进行存储或者传输，所以序列化需要将对象数据转化成二进制或者连续的字符串。序列化技术有很多种，比较常见的是Json、Xml、Protobuf等。Json是直接将对象转化成字符串，拥有很强的可读性，但缺点也很明显，那就是序列化后的数据太大了，导致需要的网络带宽也会加大，而且Json不安全，没有错误处理机制，你可以将同一个字段值转化成其他类型的数据。现在比较大型的游戏通常采用的序列化是Protobuf，Protobuf是协议定义型的，在使用时你需要定义你的数据类型，而且因为Protobuf在序列化时是用ID作为标识符，而不是字段名来标识，所以序列化后的Protobuf数据很小。对于游戏来说，Protobuf支持函数引用定义，解决了函数重复定义的问题。使用Protobuf后也可以用协议定义文件来生成MD5，以次来标识不同游戏版本的网络协议接口，以防老版本的客户端连接新版本的服务器，造成数据错误。
协议工厂

Json序列化时可以将函数名序列化进去，数据包到达服务器后，服务器根据函数名调用注册的RPC函数，但Protobuf序列化时并不会将函数名的信息带进去，Protobuf只会序列化协议参数数据，所以要使用Protobuf进行服务器序列化时，还需要一个新字段来标识这些数据是来自哪个协议的数据。通常是用一个ID来表示协议函数，那么哪个协议ID代表哪个函数了？这时候就会需要协议工厂功能。定义好协议文件后，将协议文件转化成代码文件时，通常会给每个协议一个ID，然后生成一个协议工厂代码文件，这个工厂代码就是根据ID来调用对应函数。

Factory.png

服务继承

Wind整个项目的核心代码是Engine目录下的SrvEngine.py 其他所有代码都是以组件的形式附加到这个文件下。Engine拥有一款引擎的所有功能，但并不作具体的逻辑服务使用，具体的逻辑服务需要继承Engine，然后添加各个逻辑服务的一些特定功能，具体服务在service 目录下，目前有Gateway服务和Game服务。各个服的具体设计可以参考这边文章

		自动登录	找回密码
密码			立即注册

Wind分布式游戏服务器引擎的实现

本帖子中包含更多资源