大家都在用的开源游戏服务端框架大盘点

但是，都2024年了，谁还从零开始构建自己的服务器呢？

站在巨人的肩膀上，才能推进文明的进步。

麒麟子从 2013 年开始，就一直处于引擎、客户端、服务端都要涉及的状态。

在这十年中，有一些曾经流行的框架逐渐淡出了大家的视野，而有一些框架则经久不衰。

基于更新情况、易用性和流行程度，麒麟子整理了目前游戏开发中常用的框架给大家，希望对大家有帮助。

TSRPC

• 开发语言：TypeScript
• star：1.8k
• 地址：https://tsrpc.cn/

TSRPC 是一个专为 TypeScript 设计的全栈 RPC 框架，经千万级用户验证，适用于 HTTP API、WebSocket 实时应用、NodeJS 微服务等。

使用 TSRPC 可以非常容易地构建出分布式框架。

麒麟子自己的 TGX 游戏全栈开发框架，就是基于 TSRPC 构建的，真的很好用。

Colyseus

• 开发语言：TypeScript
• star：5.7k
• 地址：https://github.com/colyseus/colyseus

Colyseus 是一个多人游戏网络服务框架，提供了许多客户端 SDK，可以轻松和 H5小游戏引擎对接。

并且官方还提供了托管服务，使你部署起来非常简单。

美中不足的是，中文资料几乎为 0，对于中国大部分开发者来说，体验感不太好。

并且官方文档相对来说比较乱，并没有完整的使用教程。

英文能力不错的，并且有海外服务托管需求的开发者，可以考虑研究一下。

skynet

• 开发语言：lua
• star：skynet 是云风大神开源的一套基于 c + lua 打造的轻量级 actor 模型的分布式服务端框架。

使用 skynet 可以很容易就构建出高效率、稳定的游戏服务器。

并且，还有大佬专门为 Skynet 写了一本书，叫《百万大线：大型网络游戏服务端开发》，值得一读。

麒麟子曾经参与的项目中，一款 FPS 和一款 ARPG 使用过 skynet，非常顺手。

美中不足的是，lua 这个语言的生态很弱，许多东西需要自己造。

加上开发只能在 linux 环境，如果想要在windows环境下开发，需要配合虚拟机。

如果本身对 lua 熟悉，或者客户端逻辑使用的是 lua 语言，skynet 是一个不错的选择。

ET

• 开发语言：C#
• star：8.7k
• 地址：https://github.com/egametang/ET

ET Framework 是一个基于 Actor 模型的 C# 服务端框架。并且配备了 Unity 客户端库，主要在 Unity 生态中比较流行。

采用 ET 框架制作的网络游戏案例很多，小到个人，大到团队都在用。

同时， ET 框架还有配套的诸多新手课程，对于熟悉 C#，或者客户端使用 C# 语言的开发者来说，非常不错。

due

• 开发语言：Golang
• star：381
• 地址：https://github.com/dobyte/due

这是一个服务端大佬使用 Golang 编写的高性能游戏服务端框架，其节点式的抽象架构使我们很容易写出可扩展的分布式游戏服务器。

美中不足的是使用案例较少、理解门槛较高。

但以麒麟子的观察来看，这个项目的实用价值非常高，并且更新频繁，值得期待。

ioGame

• 开发语言：Java
• star：837
• 地址：https://github.com/iohao/ioGame

这是一个实用性非常强的 Java 游戏服务端方案，作者写了近 30 万字的说明书。

但可能是宣传比较低调，star 数量并不高。喜欢 Java 的朋友可以试试。

麒麟子的好几个朋友公司，Java 游戏服务端使用的都是这个 ioGame。

Pomelo（已停更）

• 开发语言：Javascript
• star：11.9k
• 地址：https://github.com/NetEase/pomelo

Pomelo 是网易团队开源的一个基于 NodeJS 的游戏服务端框架，配置了完整的游戏服务和Web服务。

但这个项目于 2019 年停更了。如果对 Pomelo设计理念很喜欢，想要继续使用的朋友，这里有两个变种可以选择：

Pinus

Pomelo 的 TS 版本，特性与 Pomelo 一样，只是变成了 TS 版本，不怎么更新。

• 地址：https://github.com/node-pinus/pinus
• Githu Stars：1.8k

Pitaya（推荐）

Pomelo 的 Golang 版本，是一个有线上产品的团队开源出来的框架，更新频率不算高，但一直保持更新。

• 地址：https://github.com/topfreegames/pitaya
• Github Stars: 2.3k

写在最后

对于服务端框架的选择，麒麟子建议按下面的情况来选：

• 如果有祖传的、稳定的、满足需要的方案，就优先使用。
• 优先选择还在更新的、用的人多的
• 优先选择编译型语言（PHP/LUA/PYTHON就算了）
• 优先选择前后端同一个语言的

上面的这些框架，要么过于追求通用，只完成了一些底层建设，比如 TSRPC、skynet、due。

导致用户在构建项目时，依然需要完成大量的基础工作。

还有一些框架，追求大而全，塞了太多用得到和用不到的东西，学习成本很高。比如 ioGame、Pomelo、ET、ColySeus。

对此，麒麟子认为，服务端解决方案应该做到精而美，要针对具体的游戏类型进行构建，才能减少大家的使用成本。