游戏服务器
管的不只是，还有你的玩家是谁、他们和谁一起玩。
选游戏服务器，要看账号、好友、聊天和排行榜这些社区功能，而不只是跑规则的速度。先列出需要的功能，再把 Nakama 和其他方案比一比。
按社区功能来选，而不是按游戏循环
游戏服务器做的是两件很不一样的事。一件是游戏本身——移动棋子、判定命中、保持世界一致。另一件是围绕游戏的一切，而这第二件事，比新手想的大得多。决定玩家明天还回不回来的，也正是它。
在比较帧率之前，先数一数下面这些里，有几项是你不得不自己造、自己保安全、自己运维的：
- 账号与登录——设备、邮箱、Apple、Google、，还要把它们绑到同一个玩家身上，换设备也能接着玩。
- 聊天与论坛——一对一、群聊、房间聊天，断线重连后还在的历史记录，外加举报和拉黑。
- 公会与好友——入会申请、角色与、成员列表、（现在谁在线）。
- 排行榜与锦标赛——每日每周重置、同分排序规则，以及把作弊者挡在榜首之外。
- 推送与内购——告诉玩家体力回满了，以及在发放东西之前先是不是真的。
Docker——服务器最终是这么跑起来的
不管你选哪个服务器，它总得跑在某个地方——而今天这个「地方」几乎总是。 把服务器和它运行所需的一切——、、配置——打成一个整体。做出来的这一个镜像，在你的笔记本上和在别国租来的机器上，表现完全一样。
对游戏服务器来说，这一点更加重要，因为游戏从来不是一个。服务器之外还有，通常还有。它们得互相找到对方，并按正确的顺序启动。用 Docker，一整页安装说明就缩成一个文件加一条命令。后面标签页要讲的器 ，官方快速上手也是用 来讲的。
需要懂的四个词
Compose——一个文件搞定整套
游戏后端是若干必须一起启动的容器。Docker Compose 把它们全部——服务器、数据库、缓存——连同数据卷、网络、谁等谁，一起写进一个 文件。然后一行 就能把整套跑起来，而复制到真实服务器上的，也是同一个文件。
这就是你今晚就能试 Nakama（后面会讲到的游戏后端服务器）的原因。它官方的快速上手就是一个两服务的 compose 文件，跑一条命令，本机上就有了一个带数据库的可用游戏后端。系统里不装任何东西，之后也没什么要卸载的。
新手常踩的三个坑
- 删掉数据卷，就等于删掉数据库。带上清理数据卷的命令，会连玩家数据一起干净利落地抹掉。跑任何清理命令之前，先弄清楚它会动哪些卷——而且在你以惨痛方式弄清楚之前，先。
- 一个主机端口，只能有一个进程。要是已经有东西占着那个端口，第二个容器就干脆起不来。在跑多个站点的机器上，这是最常见的原因；解法是别对外暴露端口，让前面的一个按分流。
- 起不来，就去读日志。容器失败几乎都会在自己的里把原因写出来，而新手几乎都在靠猜。把读日志放在第一步，别放在最后一步。
SONUB 由一个 Compose 文件里描述的多个容器运行——和在后台干活的 worker（和）、PostgreSQL、、负责实时的 ，以及备份。它们前面的共用反向代理接收 连接，解密后再转给里面。发布一次改动，就是把传上去、重建服务。为了游戏服务器学会 Docker，等于顺带学会了以后你做的其他东西该怎么部署。
SpacetimeDB
走的是一条和普通游戏服务器不同的路：本身就是服务器。你不用另写一个去和数据库对话的游戏服务器，而是上传一个用 、 等语言写的，其中的函数（）在数据库里运行并修改表。 reducer 来改变状态，并需要的表，立刻收到变化的行。因为系统只有一套，所以没有另外要的服务器进程，也没有让两套系统保持一致的同步。
所以在做持续存在的世界时，它是真的优雅，结构简单到一个人能把全貌装进脑子里。代价是它还年轻、较小，而且思维方式的转变是实打实的功课——它简单，但不是你已经会的那一套。
Nakama 是什么
是 Heroic Labs 出的器，用 写成，以单个加一个 兼容的形式发布。它不是同步，也不是——它是夹在两者之间的那一层：知道你的玩家是谁、拥有什么、正在和谁一起玩。
开箱即用，它提供这些：
- 身份与认证 — 设备 、邮箱、Apple、Google、Facebook、 或自定义。一个账号绑定多种凭据，跨平台通用。
- — 带的 文档，逐对象的归属和访问规则。玩家的存档就放在这里。
- 社交 — 好友、群组与、，以及聊天（一对一、群聊、房间）和消息历史。
- 竞技 — 可配置重置周期的与锦标赛，外加按属性做的。
- 经济系统 — 支持的钱包，以及 Apple、Google、Steam 的。
- 实时 — 与 ，还有一个由服务器来做判定的对局——你自己写服务端的 循环。
- 运行时 — 用 Go、 或 扩展服务器：注册自己的 ，并在任意内置操作的前后挂。
本页把 Nakama 当作若干选项之一来讲。本站自己跑在 、PostgreSQL、 和 上，并没有用 Nakama。我们在介绍一个工具，而不是在介绍自家。
它真正的好处
它不擅长什么
决定之前该知道的事。这些都不是什么秘密，而是上面那些设计取舍带来的必然结果。
替代方案
并不存在一个「和 一样好」的东西——这个领域是按你想优化什么来分岔的。先想清楚你的难点在哪，再来挑。下面的「」指对局之外的功能（账号、好友、聊天、存档、），「」指上线后运营活动、商店和更新。
气质最接近的——开源、可自托管
| 语言 | 强项 | 相比 Nakama 的弱点 | |
|---|---|---|---|
| / | 同类里最好的自动状态同步、内置匹配，以及 、、、、 的 。 | 只管实时房间——没有身份、存储、社交、经济、排行榜。元层要你自己造。 | |
| / | 一种根本不同的模型：就是服务器。查询，你写的是 而不是。做持续世界类游戏时真的优雅。 | 还年轻、较小，而且思维方式的转变是实打实的功课。 | |
| Rivet | Rust ，JS/TS 脚本 | ，可；游戏服务器、匹配、认证，外加脚本——最接近完整替代 Nakama 的一个。 | 社区较小，而且公司转向了通用的定位，游戏方向被稀释了。 |
| + | 有 Google 背书，是机群的行业标准。 | 解决的是另一个问题——完全没有元层。它是和 Nakama 搭配用的，不是用来替代它的。 |
托管与商业方案
- — 微软的产品，功能面在同类里最宽——LiveOps、、分群、分析、经济系统。匹配和专用服务器都有，但只跑在 上。按用量计费，不归你。
- AccelByte — 企业级，也是唯一自己做专用服务器编排的竞争者。定价是给拿了投资的工作室看的。
- Pragma — 自我定位是面向长线运营游戏的「后端」：深度定制、、服务器分配、背包、成长、战令和商店。商业阵营里，理念上和 Nakama 最像的一个。
- (Fusion / Quantum) — 先是同步，其次才是后端。Quantum 的在竞技动作游戏里无出其右，但它是带服务的网络同步产品，而不是反过来。
- LootLocker · brainCloud · Beamable — 托管、上手快、也更薄。LootLocker 没有匹配也没有服务器；Beamable 只做，实时部分转给别人。游戏几乎不需要后端时，用它们挺好。
这个领域的整合比多数领域都快——这块的出现过没怎么预告就关停或退出的情况。如果你打算做一个要跑好几年的长线服务，这就是选可自托管方案的理由。
该怎么选
- 难点在实时同步，元层很简单 →
- 要做持续存在的共享世界，也愿意重新想架构 →
- 需要身份、社交、经济和排行榜，还想自托管 →
- 需要按对局拉起专用服务器机群 → 配 ，或者 ——旁边再放一个
- 宁可买 LiveOps 工具，也不想自己造 → PlayFab 或 Pragma
- 已经有自己的实时服务器了 → 只把元服务交给 Nakama，是常见也合理的做法
如果你偏好、又不想，诚实的候选就三个：Nakama、Colyseus，或者自己造元层。选 Nakama 的交易是这样的——你接受一个又大又有主见的 ，换来省下造好友、聊天、钱包、的半年时间。该问的问题是：我这游戏的元层，是不是足够贴近 Nakama 的假设，以至于我会是在扩展它，而不是在跟它较劲。