C#游戏服务器开发框架设计与架构详解

news2024/9/20 22:26:05

我一直在思考一个问题，什么样的服务端框架最好用，最适合? 经过这些年的项目经验，其实最好用，最适合的游戏服务端框架就是自己结合公司项目需求,团队特点与技术能力,自己整合的游戏框架是最好用的。

很多新手会担心自己整合的框架不能商用，这个担心完全没有必要，现在行业的发展已经很成熟，每个模块都有成熟的解决方案来提供支撑，我们要做的就是整合起来，组织我们项目逻辑的开发方式而已，所以现在的行业设计一个游戏服务端框架远比大家想象的简单和稳定。今天给大家分享一下我们最新课程《C#服务端+双端(Unity/Cocos) SLG项目实战》中服务端框架的设计模式与组织项目的思想。希望能给大家带来一些启发。

对惹，这里有一个游戏开发交流小组，大家可以点击进来一起交流一下开发经验呀！

C# 服务端所依赖的第三方基础库

先给大家列举一下我们选择的一些基础服务的框架方案，使用NuGet包管理器很方便的就安装配置好了。

DotNetty: 网络服务，http服务，WebSocket服务支撑;

Protobuf-net: 对象的序列化/反序列化;

SqlSugarCore: 基于ORM的与mysql数据库交互通讯的服务支撑;

Nlog: 对游戏服务端的日志打印提供服务支撑;

Microsoft.Extensions.Configuration: 对服务器与游戏配置的服务支撑;

Litjson: 对Json编码解码的服务支撑;

StackExchange.Redis: 对与Redis Server交互的操作服务支撑;

EnyimMemcachedCore: 对memchach的内存缓存服务支撑;

LogicLooper:对游戏服务端状态同步帧同步的帧率控制的服务支撑;

这些库我们使用NuGet包管理器安装好就可以直接开发了(如图1-1)。

图1-1: 游戏服务端项目依赖的第三方库

我们服务端开发中的所有基础模块都有成熟的第三方库，有了这些第三方库的加持，你做的游戏服务端框架，想不稳定都难^_^。

高性能高并发服务端框架设计架构流程详解

先上架构图1-2，对照架构图从左到右来看下整个框架的结构。

图1-2

关键点1: 支持多种数据通讯

支持TCP Socket, WebSocket Http三种方式与客户端进行数据通讯,拿到数据后走后续通用的工作线程来进行请求的逻辑处理。

关键点2: 多线程发挥CPU的多核优势

为了实现高性能与高并发，充分发挥服务端机器CPU的多核优势，我们采用的是工作线程池的模式来驱动迭代上层的各种服务与处理。比如，网络IO，日志打印，数据库存储，游戏业务逻辑等。

关键点3: 一切的业务流程都从Entry开始;

服务端处理的每个请求都会走统一的入口Entry，这样让我们业务逻辑的维护就可以从Entry开始了。比如账号系统相关的逻辑处理，可以写入AuthEntry中，这样后期维护的时候，遇到登录的流程维护，直接从AuthEntry开始。

图1-3

关键点3: 具体的处理流程逻辑交给Process

如上图1-3,Entry不写具体的业务逻辑，直接调用特定的Process代码, 由Processer来处理每个对应的具体业务逻辑的流程。Processer来维护流程代码，功能代码由底层框架的FrameWork，系统API函数，自己编写的功能函数等来作为服务支撑。

关键点4: 扁平化的数据对象

把服务端的每个玩家数据，Boss数据，NPC数据我们都做好扁平化设计，每个数据对象都是纯数据，没有任何的代码逻辑。这样服务端处理每个个体数据时都非常地简单与清晰，避免复杂地继承关系。如每个玩家的Entity数据，由基本信息，战斗信息，任务信息等相关组件数据组成。这些数据对象提供给Processer处理与访问。

关键点5: Framework的基础服务的支撑

Framework对整个基础的一些服务提供支撑，比如数据库服务，日志服务，网络服务等。同时针对游戏行业的需求，会有一些游戏相关的特定库的支持，比如 RVO动态避障，寻路导航，物理引擎等。C#在这块也有很多成熟的游戏相关的库。

关键点6: 业务逻辑通常开发方式

这个对于框架来说是最重要的，因为等框架做好后，就是用它来开发扩展业务逻辑。框架好不好用,团队协作是否顺畅，任务分配是否清晰就取决于它了。我们采用流程+数据的模式来开发新业务:

Step1:给新业务添加一个Entry类，并注册好对应的服务;

Step2:定义好数据通讯协议的格式结构;

Step3:定义业务逻辑功能需要的数据组件,并添加到Entity;

Step4: 编写业务逻辑对应的Processer流程，完成对应功能;

关键点7:游戏核心战斗线程的特定调度与并行扩展

与普通的业务逻辑流程处理不一样，游戏核心战斗场景，多个玩家同时战斗的处理一般在一个线程里，而不是用线程池中的任意线程调度执行。所以我们提供机制，同时游戏的玩家的同一战斗任务在一个线程中调度。不同的地图or副本等可以扩展不同的线程来提供服务。

End

纯数据结构对象扁平化,业务逻辑流程化,多线程并发调度与特定战斗线程的调度处理。业务代码流程清晰，没有过多的继承体系与模板,将简单胜于花哨。这样使得很多初始开发人员也能上手开发游戏服务端的业务。每个网络请求的处理流程非常的简单与清晰。