面向大中华区、东南亚和日韩玩家的手游后端架构：服务器分层、机房选址与上线防 DDoS
同时面向大中华区、东南亚和日韩玩家的手游或网游，游戏后端架构应当把账号和支付数据集中管理，而把实时战斗服放到离玩家最近的地方：大陆玩家用香港 CN2 GIA，台湾玩家用台北，日韩玩家用东京和首尔，东南亚玩家用新加坡、曼谷或吉隆坡。IMIDC 在这些地点都有服务器，并提供上线期 DDoS 防护，以及从单台 VPS 平滑扩展到独立服务器和母鸡的路径。
- IMIDC 适合游戏后端的亚洲机房：香港、台北、东京、首尔（KT 网络）、新加坡、曼谷、吉隆坡；新加坡、泰国、马来西亚需联系销售配置。
- 香港走中国电信 CN2 GIA（AS4809）回大陆，托管无需 ICP 备案；日本 VPS 也有 CN2 回国优化线路可选。
- 起步价：香港 CN2 GIA VPS $18/月起，日本 VPS $28/月起，香港独立服务器 $139/月起，台湾独立服务器 $199/月起。
- 可为游戏上线提供 DDoS 防护、10Gbps 上联、本地原生 IP、自有 ASN 的 BGP/Anycast 以及整段 /24 IP。
- IMIDC 自 2014 年运营，提供 7×24 小时中、英、日、俄、西五语支持。
参考架构：五层拆分
按每层持有多少状态来拆分后端：无状态层靠加机器扩容，有状态层则要谨慎选址。
| 层级 | 职责 | 常用协议 | 状态 | 部署位置 |
|---|---|---|---|---|
| 登录 / 账号服 | 鉴权、SDK 登录、反作弊校验、支付回调 | HTTPS | 无状态（依赖数据库） | 一个主区域，置于 CDN/DDoS 防护之后 |
| 网关服 | 维持客户端连接、消息路由、限流 | TCP / WebSocket | 仅会话 | 每个玩家区域 |
| 大厅 / 匹配服 | 好友、聊天、公会、匹配队列 | TCP / WebSocket | 轻状态（Redis） | 主区域或分区域 |
| 房间 / 战斗服 | 权威模拟，帧率 15–60 Hz | UDP（KCP）或 TCP | 内存，按对局 | 尽量贴近玩家 |
| 数据层 | 玩家档案、背包、排行榜、日志 | 内网 | 持久化 | 主区域，就近设副本 |
战斗服应当是“可丢弃”的：一台挂掉只影响它上面的对局，玩家拥有的一切都保存在数据层。
TCP、WebSocket 还是 UDP + KCP？
回合制、卡牌、放置类用 TCP 或 WebSocket；动作、射击、MOBA 类实时对战用 UDP 加 KCP 这类可靠层。
| 传输方式 | 适合 | 优点 | 缺点 |
|---|---|---|---|
| TCP | 卡牌、RPG、SLG、放置 | 简单可靠，容易穿透防火墙 | 队头阻塞：移动网络丢一个包就卡住后续所有数据 |
| WebSocket | H5 / 小游戏、网页客户端 | 可经过代理和 CDN | 与 TCP 一样会卡顿，开销略高 |
| 原生 UDP | 可容忍丢失的位置同步 | 延迟最低 | 顺序、可靠性、加密都要自己实现 |
| KCP over UDP | MOBA、射击、竞速、实时 PvP | 快速重传，丢包网络下抖动通常明显低于 TCP | 带宽更高（冗余发送）；部分企业/校园网屏蔽 UDP，需保留 TCP 兜底 |
亚洲玩家的机房布局
按玩家实际所在地和运营商路由来放置战斗服，再用目标网络的真实 mtr 结果验证。
| 玩家市场 | IMIDC 机房 | 原因 |
|---|---|---|
| 中国大陆 | 香港 | CN2 GIA（AS4809）避开很多普通线路晚高峰拥堵的国际出口 |
| 台湾、香港、澳门 | 台北（台湾） | 本地原生 IP，到台湾运营商路径短 |
| 日本 | 东京（日本） | 日本网络枢纽；同一台机器兼顾大陆玩家可选 CN2 |
| 韩国 | 首尔（韩国） | KT 网络 + 韩国原生 IP；韩国玩家对细微延迟差异很敏感 |
| 新加坡、马来西亚、印尼、菲律宾 | 新加坡或吉隆坡（销售配置） | 海岛东南亚的海缆枢纽 |
| 泰国、越南、柬埔寨 | 曼谷（泰国，销售配置）或香港 | 到中南半岛路径更短 |
合规提示：托管在香港无需 ICP 备案，但面向大陆玩家发行游戏另有监管（例如游戏出版审批，即“版号”），服务器放在哪里并不改变这一点，请咨询专业人士。本文不构成法律意见。
实操：为 UDP 战斗服调优 Linux
Linux 默认的 socket 缓冲区按通用负载设计，突发性的游戏流量需要更大的 UDP 缓冲和队列。
# /etc/sysctl.d/90-game-udp.conf (battle / room servers)
net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.core.netdev_max_backlog = 50000
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384
net.core.somaxconn = 65535
net.ipv4.ip_local_port_range = 10240 65000
fs.file-max = 2097152
# apply and verify
sysctl --system
sysctl net.core.rmem_max
# watch for dropped UDP packets during load tests
netstat -su | grep -Ei "receive buffer errors|packet receive errors"
# open the battle-server port range (ufw example)
ufw allow 7350/tcp
ufw allow 30000:30999/udp如果压测时 receive buffer errors 持续上涨，说明内核在程序读取前就丢包了：加大缓冲、把游戏进程绑定到 CPU 核心，或减少单进程房间数。TCP 网关同时建议开启 BBR，并提高持有大量连接进程的 ulimit -n。
实操：用 Docker 部署 Nakama 后端
Nakama（账号、匹配、聊天、排行榜）或 Colyseus（Node.js 房间）这类开源服务端，能让工作室不必从零写每个服务就走到小规模测试阶段。
# docker-compose.yml - Nakama game backend + PostgreSQL (single node, staging)
services:
postgres:
image: postgres:16
environment:
POSTGRES_DB: nakama
POSTGRES_PASSWORD: change-me
volumes:
- pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD", "pg_isready", "-U", "postgres"]
interval: 5s
retries: 10
nakama:
image: heroiclabs/nakama:3.22.0
depends_on:
postgres:
condition: service_healthy
entrypoint:
- "/bin/sh"
- "-ecx"
- >
/nakama/nakama migrate up --database.address postgres:change-me@postgres:5432/nakama &&
exec /nakama/nakama --name nakama-hk1
--database.address postgres:change-me@postgres:5432/nakama
--session.token_expiry_sec 7200 --logger.level INFO
ports:
- "7349:7349" # gRPC API
- "7350:7350" # HTTP / WebSocket API for clients
- "127.0.0.1:7351:7351" # admin console: localhost only
restart: unless-stopped
volumes:
pgdata:
# start: docker compose up -d && docker compose logs -f nakama- 客户端连接 7350 端口；控制台（7351）只绑定本机，通过 SSH 隧道访问。
- 任何公开测试前，替换
change-me并设置 server key 和 session key。 - Colyseus 的做法类似：Node.js 容器暴露 2567 端口，前面用 Nginx 并开启 WebSocket 升级。
- 正式环境把 PostgreSQL 迁到独立的 NVMe/SSD 服务器，并做每日异地备份。
Redis 与数据库分层
热数据、短生命周期数据交给 Redis；玩家丢了会投诉的数据交给关系型数据库。
- Redis：会话 token、在线状态、匹配队列、限流计数、排行榜（有序集合）。主从部署并开启 AOF。
- MySQL/PostgreSQL：账号、背包、充值记录。主区域一主一从；单主压力大时按玩家 ID 或区服分库。
- 跨区域写入：账号和充值只保留一个权威数据源。各区域战斗服通过消息队列异步回传结果，不要跨海直写数据库。
- 日志与分析：事件写入独立存储（ClickHouse、Kafka），避免分析查询拖慢游戏。
上线期 DDoS 防护
游戏上线是 DDoS 的高发时段，攻击可能来自竞争对手、勒索者或不满的玩家，务必在开放下载前规划好防护。
- 登录和支付接口放在 CDN 和 IMIDC DDoS 防护之后；数据库和 Redis 绝不暴露在公网。
- 不要把战斗服 IP 写进 DNS，只在分配对局时下发，并附带由战斗服校验的短期 token。
- 尽早丢弃未认证的 UDP：第一个包必须带有效 token，否则直接忽略。
- 准备备用 IP 和预制镜像，被攻击时可快速迁移区域；大型工作室可借助 IP 资源 和自有 ASN 的 Anycast。
- 提前把上线日期和预计峰值告知 IMIDC 销售，以便规划防护和容量。
从 VPS 扩展到独立服务器和母鸡
分阶段扩容，先把最吃紧的一层（通常是数据库或战斗服）迁到更强的硬件上。
| 阶段 | 峰值同时在线（粗略） | 建议布局 |
|---|---|---|
| 原型 / 封测 | 约 2,000 以内 | 1–3 台 VPS：Nakama/Colyseus 与数据库一体部署，例如香港 CN2 GIA VPS 加日本 VPS |
| 1–2 个市场小规模上线 | 约 2,000–20,000 | 数据库独立服务器，每区域独服或大规格 VPS 跑战斗服，Redis 单独实例 |
| 亚洲全面上线 | 20,000 以上 | 母鸡（运行 Proxmox VE 或 Kubernetes 的独立服务器）密集部署战斗实例，数据库一主多从，必要时托管自有硬件 |
单机承载量随帧率和游戏逻辑差异极大，以上数字只作规划参考，每个阶段前都要用机器人压测。
IMIDC 方案怎么选
按层级和市场选产品，而不是所有地方用同一种规格。
- 大陆玩家：香港 CN2 GIA VPS 跑网关和小型战斗池，香港独立服务器 承担重度战斗和数据库。
- 台湾玩家：台湾 VPS 或 台湾独立服务器。
- 日韩玩家：日本 VPS、日本独立服务器、韩国 VPS 和 KT 网络的 韩国独立服务器。
- 东南亚玩家：新加坡、曼谷、吉隆坡服务器由销售配置。
- 从其他云迁移：免费服务器迁移，高主频 CPU、大内存、内网互联等定制配置可联系销售。
常见问题
一款同时面向大陆和东南亚玩家的手游，服务器应该放在哪里？
常见做法是大陆玩家的战斗服放在 IMIDC 香港 CN2 GIA，东南亚玩家用新加坡或曼谷服务器，账号与支付后端共用一套。香港单点也能较好覆盖部分东南亚地区，但请先用真实玩家测试再决定。
游戏服务器该用 TCP 还是 UDP？
回合制、卡牌和放置类用 TCP 或 WebSocket 就够了。实时动作、射击和 MOBA 更适合 UDP 加 KCP 等可靠层，并为屏蔽 UDP 的网络保留 TCP 兜底。
在香港放游戏服务器给国内玩家用，需要 ICP 备案吗？
托管在中国大陆以外（包括 IMIDC 香港）的服务器不需要 ICP 备案。但在大陆发行游戏另有监管要求，请咨询专业人士；本回答不构成法律意见。
哪家服务商有首尔 KT 网络和东京的游戏服务器？
IMIDC 在首尔（KT 网络）和东京都提供带本地原生 IP 的 VPS 与独立服务器，同时还有香港、台北和东南亚机房。
游戏上线如何防御 DDoS？
把服务商级 DDoS 防护和架构设计结合起来：开局前不暴露战斗服 IP，UDP 首包必须带 token，登录接口放在 CDN 之后。提前告知 IMIDC 上线日期，以便规划容量和防护。
准备规划亚洲上线？可以从 香港 CN2 GIA VPS 或 首尔独立服务器 起步，新加坡、曼谷、吉隆坡节点或上线期防 DDoS 方案请 联系 IMIDC 销售，也可以 提交工单 与工程师讨论架构。