Pitaya 是由 Top Free Games 开源的 Go 语言游戏服务器框架，设计灵感来自 starx 与 pomelo，构建在 nano 网络库之上，目标是让实时多人在线游戏的服务端可以横向扩展。这个目录目前只有三篇文章，但刚好构成一条完整的入门线索：一篇讲它是什么，一篇讲它具体强在哪，一篇把它和 Skynet 摆在一起做对比。
如果你正在为下一个项目选服务端框架，建议按「介绍 → 优势 → 对比」的顺序读完这三篇，重点不是记住 API，而是判断它的分布式模型和你的团队技术栈是否匹配。
专题速览
| 文章 | 主题 | 适合什么时候读 |
|---|---|---|
| 游戏服务器框架 Pitaya 介绍 | 框架定位、架构组成与基本用法 | 第一次听说 Pitaya，想知道它能干什么 |
| Pitaya 框架在游戏开发中有哪些具体的技术优势 | 并发、性能、扩展性与生态优势 | 正在评估要不要选它，需要具体论据 |
| Pitaya 和 Skynet 框架对比 | 设计哲学、语言、性能与运维差异 | 在 Go 与 Lua 两条技术路线之间做决定 |
框架定位
Pitaya 面向的是「一台机器扛不住、需要多进程多节点协作」的实时游戏场景。它把玩家连接、路由、房间与后端服务拆成可独立部署的组件，通过统一的 RPC 与消息机制把它们连起来，开发者写业务时不需要自己处理节点发现与消息转发。
它用 Go 写，直接受益于 Go 的并发原语与内存管理：大量长连接可以用协程承载，跨节点调用可以走内置的 RPC，部署产物是单个二进制，运维成本相对低。代价是 Go 在业务热更新上不如脚本语言灵活，需要靠滚动发布或进程级方案解决。
文章索引
| 文章 | 一句话核心内容 |
|---|---|
| 游戏服务器框架 Pitaya 介绍 | 说明 Pitaya 的定位、架构组成与基本用法，是理解整个框架的起点。 |
| Pitaya 框架在游戏开发中有哪些具体的技术优势 | 逐条拆解它在高并发、低延迟、可扩展与生态上的具体优势，而不是泛泛而谈。 |
| Pitaya 和 Skynet 框架对比 | 从设计哲学、语言选择、性能特征与运维方式逐项对比两个框架。 |
与 Skynet 的对比
| 维度 | Pitaya | Skynet |
|---|---|---|
| 语言 | Go，业务与框架同语言 | C 核心加 Lua 业务，核心与逻辑分离 |
| 并发模型 | 协程加消息，贴近 Go 原生并发习惯 | Actor 模型，服务之间只通过消息通信 |
| 热更新 | 依赖滚动发布或进程级方案 | 脚本层热更新成熟，可不停机改业务 |
| 上手成本 | 熟悉 Go 的团队几乎零学习成本 | 需要先理解服务模型与消息语义 |
| 生态与社区 | 相对小而专注，文档以官方为主 | 国内生产案例多，中文资料丰富 |
| 典型场景 | 实时对战、需要横向扩展的多人玩法 | MMO、SLG、长生命周期养成类项目 |
一句话总结：想要 Go 技术栈、部署简单、团队本来就在写 Go，Pitaya 更顺；想要业务热更新、生态成熟、中文资料多，Skynet 更稳。
选型建议
- 团队主力语言是 Go，且项目偏实时对战与快速迭代：优先考虑 Pitaya，把精力放在玩法而不是框架适配上。
- 项目是长生命周期 MMO 或 SLG，需要频繁不停机调整业务逻辑：Skynet 的脚本热更新会省下大量发布成本。
- 已经在用 Skynet 且运行稳定：不要为了换语言而迁移，除非遇到了明确的性能或人力瓶颈。
- 两个框架都不是开箱即用的完整游戏后端，账号、支付、运营后台与监控仍需自己搭。
- 无论选哪个，都建议先读「游戏服务器实战专题」里的架构方法，框架只解决通信与调度，状态归属与幂等仍要自己设计。
后续补充方向
这个目录目前只有三篇，属于框架认知层面的最小集合。后续如果要继续扩写，建议按下面几个方向补：
- 架构拆解：把连接层、路由层、房间与后端服务的实际部署形态画清楚，对照本目录里「游戏服务器集群拓扑」的思路。
- 实战工程：补一篇从零搭出可运行多人对战服务的教程，覆盖登录、匹配、房间与断线重连。
- 与 Go 生态的衔接：讲清它如何和常见的 RPC、服务发现与配置中心配合使用。
- 运维视角：补监控指标、日志采集与灰度发布这类上线后才会遇到的问题。
相关专题
| 专题 | 关联内容 |
|---|---|
| 游戏服务器总览 | 本目录所属的上一层，包含按月归档与其他框架类文章。 |
| Skynet 框架专题 | 与 Pitaya 对比最直接的另一个框架，17 篇覆盖从入门到生产。 |
| 游戏服务器实战专题 | 与框架无关的服务端架构方法，两个框架的项目都适用。 |
| 游戏总专题 | 更上层的游戏开发内容全景。 |