最近圈子里好几个朋友都在问,回合策略卡牌手游《斗罗大陆之神王降临》的服务端,能不能在自己云主机上手工搭一套跑起来。说实话,这类游戏的服务端结构并没有想象中那么玄乎,核心就是一套标准的数据库 缓存 网关 游戏逻辑进程组合,和市面上很多同类卡牌手游的部署思路几乎一致。我花了两个晚上把整套流程走通,顺便把关键步骤和踩过的坑都记了下来。这篇文章就围绕服务端搭建这个主题,从环境准备、数据库初始化、服务进程启动到客户端改IP登录,完整梳理一遍,适合有一定Linux基础、想自己折腾游戏服务端研究或搭建联机环境的朋友参考。1. 搭建前的整体思路与方案选型1.1 这套服务端到底由哪些部分组成很多人第一次拿到服务端文件,看到一堆进程和目录就发懵。其实《斗罗大陆之神王降临》的服务端和其他回合策略卡牌手游一样,大致可以拆成四块:Web服务端、数据库、缓存服务和游戏逻辑服务。Web服务端负责的是前端登录页、GM后台、支付回调这类HTTP接口,玩家打开游戏后第一个访问的目标就是它。数据库一般用MySQL,游戏角色、背包、阵容、任务进度全都落在里面。缓存服务用Redis,承载在线状态、战斗临时数据、排行榜之类的热点数据。游戏逻辑服务是核心进程,负责处理战斗结算、抽卡概率、掉落、聊天等实时逻辑,一般按照区服分成多个进程实例。理解了这个组成,后面搭建思路就很清晰了:先把MySQL和Redis跑起来,再启动Web端,最后拉起游戏逻辑进程。顺序反了就会出现各种莫名其妙的连接失败。1.2 Docker vs 裸装:我为什么推荐容器化服务端部署方式有两条路:一是直接在服务器上装MySQL、Redis、Nginx、Java/PHP运行时,手工配置;二是用Docker容器化,一条命令把整套环境拉起来。我强烈推荐后者,尤其是对只在Linux上有基础操作能力的朋友。原因很简单:这类服务端文件往往要求特定的环境版本,比如MySQL 5.7、Redis 6.0、OpenJDK 1.8,不同版本之间差异会导致进程启动失败。裸装环境一旦系统包版本和游戏要求对不上,排查起来极其痛苦。Docker镜像把这些依赖全部固化,只要服务器能跑Docker,基本不会出现环境层面的兼容问题。另外容器化还有一个好处:目录挂载方便,数据库文件、日志、配置文件都能映射到宿主机,出问题可以直接看文件,不用进容器折腾。我这次就是用Docker Compose把整套服务编排起来,修改配置、重启进程、备份数据都很快。1.3 云主机选型与系统规划《斗罗大陆之神王降临》这类回合制卡牌游戏,服务端并发压力比MMO小很多,核心瓶颈其实在内存和磁盘IO。我自己测试用的是4核8G的云主机,跑一个完整区服加数据库、缓存,内存占用大概在5G左右。如果你打算开放给十来个朋友联机,4核8G足够;要是想挑战更多人同时在线的极限,建议直接上8核16G。系统方面推荐用CentOS 7.9或者Ubuntu 20.04/22.04 LTS,这两套系统在Docker环境下表现都很稳定。需要注意一点:如果你手里拿到的服务端文件里包含一些预编译的二进制程序,尽量选择和教程一致的发行版,否则可能遇到glibc版本不兼容的问题。注意:云主机安全组和系统防火墙都要检查。Docker容器端口映射到宿主机之后,如果安全组没放行对应端口,外部玩家一样连不进来。后面我会单独列端口规划表。2. 基础环境准备:从零开始装好一台能跑游戏的机器2.1 连接云主机与基础依赖无论你用哪家云服务商,拿到云主机后的第一步都是SSH登录。Windows用户我建议直接用Windows Terminal或Xshell,Mac用户直接用自带终端就行。登录后先做两件事:更新系统源并安装基础工具。# CentOS / 兼容系统 yum update -y yum install -y wget curl git unzip zip vim lsof net-tools # Ubuntu / Debian apt update -y apt install -y wget curl git unzip zip vim lsof net-tools这些基础工具里,lsof和net-tools后面排查端口占用时会频繁用到,建议别省略。装好之后可以用free -h、df -h确认一下内存和磁盘空间,确保至少预留20G以上可用空间给数据库和服务端文件。2.2 安装Docker与Compose确认系统没问题后,直接装Docker。这里有简洁可靠的官方脚本方式:curl -fsSL https://get.docker.com | bash systemctl enable docker systemctl start dockerDocker装好后,再装Compose插件(用python3-pip或官方二进制均可以,我更推荐直接下二进制):curl -L https://github.com/docker/compose/releases/download/v2.20.2/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose chmod x /usr/local/bin/docker-compose ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose docker-compose --version看到版本号输出了,环境准备就完成了。装完可以顺手跑一下docker ps,确认Docker守护进程正常。2.3 端口规划与防火墙放行服务端启动前,最好先把端口规划想清楚。按照常见的服务端参数,《斗罗大陆之神王降临》一般会用到这些端口:服务默认端口说明Nginx/Web80前端登录页、接口网关MySQL3306游戏数据库(只对内网开放即可)Redis6379缓存服务(只对内网开放即可)游戏网关8001客户端连接的第一道入口游戏逻辑服8002/8003实际战斗与逻辑处理GM管理后台8080后台管理页面(建议限定IP访问)云主机安全组里,至少放行80、8001、8002、8080这几个端口。3306和6379不建议直接暴露公网,否则分分钟被脚本扫描爆破。系统防火墙也要同步操作:# CentOS 7 firewall-cmd --zonepublic --add-port80/tcp --permanent firewall-cmd --zonepublic --add-port8001/tcp --permanent firewall-cmd --zonepublic --add-port8002/tcp --permanent firewall-cmd --reload # Ubuntu ufw allow 80/tcp ufw allow 8001/tcp ufw allow 8002/tcp如果你手里的服务端配置里游戏端口不是8001/8002,记得以实际配置为准,我后面会讲配置文件怎么改。3. 服务端文件结构与核心配置解读3.1 目录规划与文件上传拿到服务端文件后,先在服务器上建一个专门的目录,我习惯放在/data/game下,这样备份和管理都比较清晰。用scp或者宝塔面板的FTP工具把服务端文件传上去。建议上传时保留压缩包,解压前先看一下包内结构,避免直接解压到根目录搞乱路径。一套典型的服务端文件解压后大概是这样的结构:/data/game ├── docker-compose.yml ├── sql/ # 数据库初始化脚本 ├── web/ # Web接口端源码或编译产物 ├── game/ # 游戏逻辑服务 │ ├── config/ # 游戏配置文件 │ └── lib/ # 依赖库 ├── tools/ # 工具脚本(开服、关服、清理等) └── README.txt # 搭建说明(很多分享包会带)拿到文件后第一件事:读README。不要嫌麻烦,里面往往会写清楚数据库名、端口、管理员账号、默认支付回调等关键信息。我见过不少朋友跳过这步,结果卡在数据库配置上,回头翻文档才发现README里写得明明白白。3.2 docker-compose.yml逐段解析如果服务端作者提供的是Docker Compose方案,docker-compose.yml就是整个部署的总指挥。我拿一个比较典型的配置片段来讲解:version: 3 services: mysql: image: mysql:5.7 container_name: game_mysql restart: always environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: shenwang_db ports: - 3306:3306 volumes: - /data/game/mysql-data:/var/lib/mysql - /data/game/sql:/docker-entrypoint-initdb.d redis: image: redis:6.0 container_name: game_redis restart: always ports: - 6379:6379 web: build: ./web container_name: game_web restart: always ports: - 80:80 depends_on: - mysql - redis game: build: ./game container_name: game_logic restart: always ports: - 8001:8001 - 8002:8002 depends_on: - web volumes: - /data/game/game/config:/game/config这里有几个关键点:第一,MySQL的/docker-entrypoint-initdb.d目录会自动执行里面的SQL脚本,所以数据库初始化可以做到容器一启动、库表结构自动建好。这是目前最省事的方案。第二,game容器的配置目录通过volume映射出来,意味着修改配置不需要重新构建镜像,直接改宿主机上/data/game/game/config下的文件,然后重启容器即可。第三,各服务之间的依赖顺序由depends_on控制,但这里的控制只是启动顺序,并不能保证MySQL在游戏进程启动时已经完全就绪。稳妥起见,游戏服务一般有自己的重连机制,但也有可能因为MySQL还没完全初始化而崩掉,后面我会讲加一个简单去等待的办法。3.3 游戏配置里的关键参数游戏逻辑服务的配置文件常见命名有config.lua、setting.json、game.properties等。重点要改的参数是这几个:数据库地址和账号密码:如果配置里写的是127.0.0.1:3306,而数据库在容器内,要改成宿主机IP或容器网络别名,一般写mysql即可。Redis地址和密码:同样需要匹配Redis服务的地址密码。区服ID和区服名字:正常填1、shenwang1之类。对外公告接口地址:部分客户端启动时会请求公告,这个地址一般指向Web服务器,需要改成你的服务器公网IP。端口绑定:确认游戏逻辑进程实际监听的端口和docker-compose.yml里映射的端口一致。config.lua这类配置对格式很敏感,改错一个逗号都会导致进程起不来。建议改之前先把原文件备份一份,改完用python3 -m json.tool或luac -p做语法检查。4. 数据库初始化与连接配置4.1 启动数据库容器很多朋友初始化数据库时习惯手动去执行SQL,其实Compose方案里完全可以在第一次启动时就自动完成。只要把sql目录挂载到/docker-entrypoint-initdb.d,MySQL容器首次启动时就会按文件名顺序执行脚本。执行前要确认SQL脚本里有没有包含建库语句:CREATE DATABASE IF NOT EXISTS shenwang_db DEFAULT CHARSET utf8mb4;如果有,那么docker-compose.yml里的MYSQL_DATABASE可以省略或保持一致,防止重复建库报错。如果没有,则需要使用MYSQL_DATABASE环境变量指定一个数据库名,否则导入会因为没有目标库而失败。启动方式很简单:cd /data/game docker-compose up -d mysql redis等待几十秒后,用以下命令确认容器正常运行:docker ps docker logs game_mysql --tail 50看到类似ready for connections的日志,就说明数据库已经起来了。4.2 导入SQL并处理账号数据如果服务端包没提供自动导入机制,那就需要手工导入。进入MySQL容器执行:docker exec -it game_mysql mysql -uroot -proot123456然后:source /docker-entrypoint-initdb.d/shenwang.sql; show tables;这里遇到最多的坑是SQL脚本编码问题。Windows上编辑过的SQL文件常常带BOM头,或者使用GBK编码,导入中文数据会出现乱码。解决办法是用iconv转换编码再导入:iconv -f GBK -t UTF-8 shenwang.sql shenwang_utf8.sql导入完成后,建议检查一下账号表和服务端GM表。这类游戏通常有一个管理员账号,默认密码在README里,后续可以用它登录GM后台或者获取充值道具。4.3 服务端数据库连接串修改数据库初始化完成后,回到游戏配置目录,把逻辑服和Web端的数据库连接信息改成实际值。假设MySQL运行在game_mysql容器,而同网络里的其他服务可以通过服务名访问它,那么连接地址应该填game_mysql:3306,而不是127.0.0.1。如果游戏服务运行在容器外,连接地址则填云主机内网IP:3306。这里尤其要注意:MySQL默认只允许本地登录,如果你打算从容器外连接,需要在启动参数或配置里加上--bind-address0.0.0.0,并且给远程用户授权:GRANT ALL PRIVILEGES ON *.* TO root% IDENTIFIED BY root123456; FLUSH PRIVILEGES;注意:生产环境不要把MySQL的3306端口映射到公网。仅作为内部服务使用时,可以去掉ports里3306的映射,只在Compose网络内部访问,这样能省去很多安全风险。5. 游戏服务进程启动与接口验证5.1 启动顺序:先把骨架立起来很多新手喜欢一股脑docker-compose up -d把所有服务全拉起来,结果日志刷了一屏错误。正确的顺序应该是:先起基础设施,再起网关,最后起游戏逻辑服。我在实际操作中的启动顺序:# 第一步:启动数据库和缓存 docker-compose up -d mysql redis # 第二步:确认数据库就绪(mysql容器日志出现ready for connections) docker logs game_mysql 21 | tail -20 # 第三步:启动Web端 docker-compose up -d web # 第四步:等待几秒后启动游戏逻辑服务 sleep 5 docker-compose up -d game每次启动后,都要看一眼对应容器的日志,确认没有关键报错再继续下一步。这样分层启动的好处是把问题隔离在单层,不会出现数据库没起来、游戏进程连阻塞反复重启,最后你还要花时间判断是哪一层出的问题。5.2 查看日志确认服务状态游戏逻辑服务正常启动后,日志里通常会出现一行标志性的记录,比如Server Start Success、listen on 8001等。用下面的命令持续跟踪日志:docker logs -f game_logic --tail 50看到这样的输出时基本不用担心了:[INFO] 2025-01-10 12:00:01 connect mysql success [INFO] 2025-01-10 12:00:01 connect redis success [INFO] 2025-01-10 12:00:02 load config done [INFO] 2025-01-10 12:00:03 game server start on 0.0.0.0:8001如果日志里一直刷connect refused或Auth failed,优先检查数据库和Redis配置,而不是反复重启容器。我最初折腾时就是没注意到Redis密码配置少了一位,结果游戏进程一直在数据库连接成功、Redis鉴权失败之间循环,看起来像卡死,其实原因很简单。5.3 用接口测试验证服务端是否真的能通服务端逻辑进程起来不代表客户端就能连上,还需要验证Web接口层是否正常。这里我习惯用curl做一轮简单的接口冒烟测试。先验证Web首页是否可以访问:curl -I http://127.0.0.1/再验证一个常见的登录接口(具体路径以实际包为准,多数在/api/login或/api/user/login):curl -X POST http://127.0.0.1/api/login \ -H Content-Type: application/json \ -d {account:test,password:123456}如果返回了JSON数据,说明Web接口和数据库的链路是通的。如果返回503或404,则需要检查Nginx站点配置、Web容器日志、数据库连接串这三处地方。还有一种情况:Web接口通,但游戏逻辑服连不上。这种情况通常是逻辑服端口没映射到宿主机,或者监听在127.0.0.1而不是0.0.0.0。用ss -lntp看一下容器内实际监听地址:docker exec game_logic ss -lntp如果监听的地址是127.0.0.1,需要去配置里改成0.0.0.0,否则外部客户端永远连不进来。这是很多人最容易忽略的一个细节。6. 客户端修改与登录实战6.1 Android客户端IP修改与重打包服务端全部就绪后,最后一步就是让客户端连接你的服务器。大部分Android手游客户端都会把服务器IP写在assets资源目录的一个配置文件中,常见文件有assets/config/server.json、assets/bundleinfo等。我惯用的处理流程:用Apktool反编译APK:apktool d shenwang.apk在反编译产物里搜索IP地址或域名:grep -r 192.168\|127.0.0.1\|yourdomain ./修改目标文件里的服务器地址和端口,改成你自己的公网IP或域名重新回编译:apktool b shenwang -o shenwang_new.apk对新APK进行签名签名这一步很关键。系统应用或游戏客户端通常需要签名校验,如果不签名或签名不一致,安装后可能闪退或连接失败。签名命令:keytool -genkey -alias key -keystore game.keystore -validity 3650 -keyalg RSA jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore game.keystore shenwang_new.apk key注意:部分客户端会对包名和签名做合法性校验,一旦被篡改就提示安装包损坏或请从官方渠道下载。碰上这种情况,就要检查客户端是否做了完整性校验。如果校验写在JNI库里,破解成本会高很多,这种情况就超出搭建服务端的范畴了,通常说明这套客户端本来就是给特定设备或渠道用的。6.2 客户端服务端版本号匹配改完IP后,还有一个容易踩的坑:客户端版本号和服务端配置的版本号不一致。游戏启动时,客户端会向服务端请求版本配置,如果服务端返回的版本低于客户端最低版本,就会提示请升级客户端。这个问题通常在服务端配置里可以改:{ client_ver: 1.0.1, min_ver: 1.0.1, update_url: http://你的服务器地址/pack.apk }尽量把客户端自身AndroidManifest.xml里的versionName和服务端配置保持一致,不要随意改动,否则测试时很容易出现拉取更新包失败的尴尬情况。6.3 完整登录链路自测客户端打包安装后,不要急着登录。先在客户端打开前,用电脑或手机浏览器访问服务器IP的80端口,确认Web界面能打开。这一步能帮你快速判断是客户端的问题还是服务端问题。然后打开游戏,观察以下几个节点:启动页能否拉到公告:拉不到公告通常是Web服务或公告接口地址错误输入账号密码后能否进入选服界面:卡在登录说明Web接口或数据库账号验证有问题进入选服/创角界面是否流畅:这一步涉及游戏逻辑服和数据库创建角色后能否正常进入主城:进入后卡加载或秒退,多半是配置的资源路径错误如果整条链路走通,说明服务端搭建成功。接下来就可以做充值、GM后台发道具等进一步测试了。7. 常见问题与排查技巧实录7.1 服务起不来:端口、依赖、日志三板斧服务起不来是最常见的问题。我的排查顺序固定三步:先看端口有没有被占,再看服务依赖是否都正常,最后看容器日志里的具体报错。# 查端口占用 lsof -i:8001 ss -lntp | grep 8001 # 看容器列表与状态 docker ps -a # 看关键日志 docker logs game_logic --tail 100端口被占的话,要么关掉占用进程,要么改服务端配置和Compose映射端口。依赖异常的,用docker inspect game_logic检查环境变量和网络配置。日志报错才是最后要精准定位的点,大部分问题都会在日志里留下直接线索。7.2 数据库连接失败的典型原因数据库连接失败占了这类搭建问题的一半以上。常见原因就这几类:密码错误或用户名不对:docker exec进容器,用配置里的账号密码手工登录测试权限不足:远程登录收不到授权,需要给%通配授权字符集乱码导致SQL执行失败:转换编码后重新导入内存不足导致MySQL自动退出:free -h查看内存,必要时加Swap或升级配置这里有一个实用技巧:在游戏配置里发现的连接串可能是jdbc:mysql://127.0.0.1:3306/shenwang_db,这种写法在容器内启动时指向容器自身的回环地址,而不是MySQL容器。需要改成jdbc:mysql://game_mysql:3306/shenwang_db或宿主机内网IP。一个细小的地址差别,就能让排查陷入僵局。7.3 登录超时/卡在验证界面服务端都正常启动了,但客户端打开后一直转圈、提示服务器连接超时,这个问题我建议按这个顺序排查:客户端里填的IP和端口是否正确,尤其是端口是不是映射后的宿主机端口云主机安全组是否放行了对应端口游戏逻辑服务是否监听在0.0.0.0客户端反编译后重新打包的签名是否正确是否客户端与服务端的加密协议或版本不匹配前四点都比较容易定位,第五点比较麻烦。如果你用官方最新客户端去连一套旧服务端,协议字段不匹配很可能直接握手失败,表现为登录无响应而不是明确的报错。解决办法是寻找和该服务端匹配的历史客户端版本。7.4 资源占用排查与日常维护命令服务端跑起来之后,日常维护也是个体力活。内存泄漏和僵尸进程是这类游戏的常见问题,建议养成定时查看的习惯:# 查看容器资源占用 docker stats --no-stream # 查看宿主机内存和负载 free -h uptime # 清理日志文件,防止磁盘占满 docker system prune -f服务端长时间运行后,如果发现进入游戏越来越卡,优先考虑重启游戏逻辑容器,然后观察内存是否恢复正常。重启命令很简单:docker-compose restart game但要注意:重启会踢掉当前在线的玩家,如果有朋友在玩,最好选维护时间再操作。7.5 常见问题速查表现象可能原因排查方法MySQL容器反复重启内存不足/端口占用free -h, lsof -i:3306游戏进程日志报connect refused连接地址错误/服务未起确认MySQL、Redis容器状态Redis鉴权失败配置密码与实际不一致检查.env和config配置Web接口404Nginx配置路径错误查看web容器日志客户端能打开但选服超时安全组未放行/端口映射错误curl测试游戏端口登录后创建角色失败数据库表缺失/权限不足show tables, grant授权服务端长时间运行后卡顿内存泄漏/日志膨胀docker stats, 定期重启最后说一点个人经验搭建这套回合策略卡牌手游服务端的最大心得,就是耐心分层。把服务端拆成Web、数据、缓存、逻辑四层,每一层单独验证,不要指望一次把所有容器全部拉起来就能成功。我第二次重装系统时因为图省事跳过了一层一层的验证,结果一个数据库字符集问题查了近两个小时,之后老老实实回到分层排查法,反而最快。另外,不管你是自己研究还是和朋友联机,都建议把服务端文件、SQL脚本和客户端APK备份到本地一份,Docker挂载的目录也定期做快照。这类资源在网盘和社群里经常失效,忘了备份等于白折腾一整晚。最后再分享一个小技巧:服务端配置里如果遇到不知道含义的开关,可以先保持默认,只改必改项,跑通了再逐个试功能。一次改太多参数,出了问题反而不知道是哪一项导致的。
斗罗大陆之神王降临服务端搭建全攻略：Docker容器化部署实战
最近圈子里好几个朋友都在问,回合策略卡牌手游《斗罗大陆之神王降临》的服务端,能不能在自己云主机上手工搭一套跑起来。说实话,这类游戏的服务端结构并没有想象中那么玄乎,核心就是一套标准的数据库 缓存 网关 游戏逻辑进程组合,和市面上很多同类卡牌手游的部署思路几乎一致。我花了两个晚上把整套流程走通,顺便把关键步骤和踩过的坑都记了下来。这篇文章就围绕服务端搭建这个主题,从环境准备、数据库初始化、服务进程启动到客户端改IP登录,完整梳理一遍,适合有一定Linux基础、想自己折腾游戏服务端研究或搭建联机环境的朋友参考。1. 搭建前的整体思路与方案选型1.1 这套服务端到底由哪些部分组成很多人第一次拿到服务端文件,看到一堆进程和目录就发懵。其实《斗罗大陆之神王降临》的服务端和其他回合策略卡牌手游一样,大致可以拆成四块:Web服务端、数据库、缓存服务和游戏逻辑服务。Web服务端负责的是前端登录页、GM后台、支付回调这类HTTP接口,玩家打开游戏后第一个访问的目标就是它。数据库一般用MySQL,游戏角色、背包、阵容、任务进度全都落在里面。缓存服务用Redis,承载在线状态、战斗临时数据、排行榜之类的热点数据。游戏逻辑服务是核心进程,负责处理战斗结算、抽卡概率、掉落、聊天等实时逻辑,一般按照区服分成多个进程实例。理解了这个组成,后面搭建思路就很清晰了:先把MySQL和Redis跑起来,再启动Web端,最后拉起游戏逻辑进程。顺序反了就会出现各种莫名其妙的连接失败。1.2 Docker vs 裸装:我为什么推荐容器化服务端部署方式有两条路:一是直接在服务器上装MySQL、Redis、Nginx、Java/PHP运行时,手工配置;二是用Docker容器化,一条命令把整套环境拉起来。我强烈推荐后者,尤其是对只在Linux上有基础操作能力的朋友。原因很简单:这类服务端文件往往要求特定的环境版本,比如MySQL 5.7、Redis 6.0、OpenJDK 1.8,不同版本之间差异会导致进程启动失败。裸装环境一旦系统包版本和游戏要求对不上,排查起来极其痛苦。Docker镜像把这些依赖全部固化,只要服务器能跑Docker,基本不会出现环境层面的兼容问题。另外容器化还有一个好处:目录挂载方便,数据库文件、日志、配置文件都能映射到宿主机,出问题可以直接看文件,不用进容器折腾。我这次就是用Docker Compose把整套服务编排起来,修改配置、重启进程、备份数据都很快。1.3 云主机选型与系统规划《斗罗大陆之神王降临》这类回合制卡牌游戏,服务端并发压力比MMO小很多,核心瓶颈其实在内存和磁盘IO。我自己测试用的是4核8G的云主机,跑一个完整区服加数据库、缓存,内存占用大概在5G左右。如果你打算开放给十来个朋友联机,4核8G足够;要是想挑战更多人同时在线的极限,建议直接上8核16G。系统方面推荐用CentOS 7.9或者Ubuntu 20.04/22.04 LTS,这两套系统在Docker环境下表现都很稳定。需要注意一点:如果你手里拿到的服务端文件里包含一些预编译的二进制程序,尽量选择和教程一致的发行版,否则可能遇到glibc版本不兼容的问题。注意:云主机安全组和系统防火墙都要检查。Docker容器端口映射到宿主机之后,如果安全组没放行对应端口,外部玩家一样连不进来。后面我会单独列端口规划表。2. 基础环境准备:从零开始装好一台能跑游戏的机器2.1 连接云主机与基础依赖无论你用哪家云服务商,拿到云主机后的第一步都是SSH登录。Windows用户我建议直接用Windows Terminal或Xshell,Mac用户直接用自带终端就行。登录后先做两件事:更新系统源并安装基础工具。# CentOS / 兼容系统 yum update -y yum install -y wget curl git unzip zip vim lsof net-tools # Ubuntu / Debian apt update -y apt install -y wget curl git unzip zip vim lsof net-tools这些基础工具里,lsof和net-tools后面排查端口占用时会频繁用到,建议别省略。装好之后可以用free -h、df -h确认一下内存和磁盘空间,确保至少预留20G以上可用空间给数据库和服务端文件。2.2 安装Docker与Compose确认系统没问题后,直接装Docker。这里有简洁可靠的官方脚本方式:curl -fsSL https://get.docker.com | bash systemctl enable docker systemctl start dockerDocker装好后,再装Compose插件(用python3-pip或官方二进制均可以,我更推荐直接下二进制):curl -L https://github.com/docker/compose/releases/download/v2.20.2/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose chmod x /usr/local/bin/docker-compose ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose docker-compose --version看到版本号输出了,环境准备就完成了。装完可以顺手跑一下docker ps,确认Docker守护进程正常。2.3 端口规划与防火墙放行服务端启动前,最好先把端口规划想清楚。按照常见的服务端参数,《斗罗大陆之神王降临》一般会用到这些端口:服务默认端口说明Nginx/Web80前端登录页、接口网关MySQL3306游戏数据库(只对内网开放即可)Redis6379缓存服务(只对内网开放即可)游戏网关8001客户端连接的第一道入口游戏逻辑服8002/8003实际战斗与逻辑处理GM管理后台8080后台管理页面(建议限定IP访问)云主机安全组里,至少放行80、8001、8002、8080这几个端口。3306和6379不建议直接暴露公网,否则分分钟被脚本扫描爆破。系统防火墙也要同步操作:# CentOS 7 firewall-cmd --zonepublic --add-port80/tcp --permanent firewall-cmd --zonepublic --add-port8001/tcp --permanent firewall-cmd --zonepublic --add-port8002/tcp --permanent firewall-cmd --reload # Ubuntu ufw allow 80/tcp ufw allow 8001/tcp ufw allow 8002/tcp如果你手里的服务端配置里游戏端口不是8001/8002,记得以实际配置为准,我后面会讲配置文件怎么改。3. 服务端文件结构与核心配置解读3.1 目录规划与文件上传拿到服务端文件后,先在服务器上建一个专门的目录,我习惯放在/data/game下,这样备份和管理都比较清晰。用scp或者宝塔面板的FTP工具把服务端文件传上去。建议上传时保留压缩包,解压前先看一下包内结构,避免直接解压到根目录搞乱路径。一套典型的服务端文件解压后大概是这样的结构:/data/game ├── docker-compose.yml ├── sql/ # 数据库初始化脚本 ├── web/ # Web接口端源码或编译产物 ├── game/ # 游戏逻辑服务 │ ├── config/ # 游戏配置文件 │ └── lib/ # 依赖库 ├── tools/ # 工具脚本(开服、关服、清理等) └── README.txt # 搭建说明(很多分享包会带)拿到文件后第一件事:读README。不要嫌麻烦,里面往往会写清楚数据库名、端口、管理员账号、默认支付回调等关键信息。我见过不少朋友跳过这步,结果卡在数据库配置上,回头翻文档才发现README里写得明明白白。3.2 docker-compose.yml逐段解析如果服务端作者提供的是Docker Compose方案,docker-compose.yml就是整个部署的总指挥。我拿一个比较典型的配置片段来讲解:version: 3 services: mysql: image: mysql:5.7 container_name: game_mysql restart: always environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: shenwang_db ports: - 3306:3306 volumes: - /data/game/mysql-data:/var/lib/mysql - /data/game/sql:/docker-entrypoint-initdb.d redis: image: redis:6.0 container_name: game_redis restart: always ports: - 6379:6379 web: build: ./web container_name: game_web restart: always ports: - 80:80 depends_on: - mysql - redis game: build: ./game container_name: game_logic restart: always ports: - 8001:8001 - 8002:8002 depends_on: - web volumes: - /data/game/game/config:/game/config这里有几个关键点:第一,MySQL的/docker-entrypoint-initdb.d目录会自动执行里面的SQL脚本,所以数据库初始化可以做到容器一启动、库表结构自动建好。这是目前最省事的方案。第二,game容器的配置目录通过volume映射出来,意味着修改配置不需要重新构建镜像,直接改宿主机上/data/game/game/config下的文件,然后重启容器即可。第三,各服务之间的依赖顺序由depends_on控制,但这里的控制只是启动顺序,并不能保证MySQL在游戏进程启动时已经完全就绪。稳妥起见,游戏服务一般有自己的重连机制,但也有可能因为MySQL还没完全初始化而崩掉,后面我会讲加一个简单去等待的办法。3.3 游戏配置里的关键参数游戏逻辑服务的配置文件常见命名有config.lua、setting.json、game.properties等。重点要改的参数是这几个:数据库地址和账号密码:如果配置里写的是127.0.0.1:3306,而数据库在容器内,要改成宿主机IP或容器网络别名,一般写mysql即可。Redis地址和密码:同样需要匹配Redis服务的地址密码。区服ID和区服名字:正常填1、shenwang1之类。对外公告接口地址:部分客户端启动时会请求公告,这个地址一般指向Web服务器,需要改成你的服务器公网IP。端口绑定:确认游戏逻辑进程实际监听的端口和docker-compose.yml里映射的端口一致。config.lua这类配置对格式很敏感,改错一个逗号都会导致进程起不来。建议改之前先把原文件备份一份,改完用python3 -m json.tool或luac -p做语法检查。4. 数据库初始化与连接配置4.1 启动数据库容器很多朋友初始化数据库时习惯手动去执行SQL,其实Compose方案里完全可以在第一次启动时就自动完成。只要把sql目录挂载到/docker-entrypoint-initdb.d,MySQL容器首次启动时就会按文件名顺序执行脚本。执行前要确认SQL脚本里有没有包含建库语句:CREATE DATABASE IF NOT EXISTS shenwang_db DEFAULT CHARSET utf8mb4;如果有,那么docker-compose.yml里的MYSQL_DATABASE可以省略或保持一致,防止重复建库报错。如果没有,则需要使用MYSQL_DATABASE环境变量指定一个数据库名,否则导入会因为没有目标库而失败。启动方式很简单:cd /data/game docker-compose up -d mysql redis等待几十秒后,用以下命令确认容器正常运行:docker ps docker logs game_mysql --tail 50看到类似ready for connections的日志,就说明数据库已经起来了。4.2 导入SQL并处理账号数据如果服务端包没提供自动导入机制,那就需要手工导入。进入MySQL容器执行:docker exec -it game_mysql mysql -uroot -proot123456然后:source /docker-entrypoint-initdb.d/shenwang.sql; show tables;这里遇到最多的坑是SQL脚本编码问题。Windows上编辑过的SQL文件常常带BOM头,或者使用GBK编码,导入中文数据会出现乱码。解决办法是用iconv转换编码再导入:iconv -f GBK -t UTF-8 shenwang.sql shenwang_utf8.sql导入完成后,建议检查一下账号表和服务端GM表。这类游戏通常有一个管理员账号,默认密码在README里,后续可以用它登录GM后台或者获取充值道具。4.3 服务端数据库连接串修改数据库初始化完成后,回到游戏配置目录,把逻辑服和Web端的数据库连接信息改成实际值。假设MySQL运行在game_mysql容器,而同网络里的其他服务可以通过服务名访问它,那么连接地址应该填game_mysql:3306,而不是127.0.0.1。如果游戏服务运行在容器外,连接地址则填云主机内网IP:3306。这里尤其要注意:MySQL默认只允许本地登录,如果你打算从容器外连接,需要在启动参数或配置里加上--bind-address0.0.0.0,并且给远程用户授权:GRANT ALL PRIVILEGES ON *.* TO root% IDENTIFIED BY root123456; FLUSH PRIVILEGES;注意:生产环境不要把MySQL的3306端口映射到公网。仅作为内部服务使用时,可以去掉ports里3306的映射,只在Compose网络内部访问,这样能省去很多安全风险。5. 游戏服务进程启动与接口验证5.1 启动顺序:先把骨架立起来很多新手喜欢一股脑docker-compose up -d把所有服务全拉起来,结果日志刷了一屏错误。正确的顺序应该是:先起基础设施,再起网关,最后起游戏逻辑服。我在实际操作中的启动顺序:# 第一步:启动数据库和缓存 docker-compose up -d mysql redis # 第二步:确认数据库就绪(mysql容器日志出现ready for connections) docker logs game_mysql 21 | tail -20 # 第三步:启动Web端 docker-compose up -d web # 第四步:等待几秒后启动游戏逻辑服务 sleep 5 docker-compose up -d game每次启动后,都要看一眼对应容器的日志,确认没有关键报错再继续下一步。这样分层启动的好处是把问题隔离在单层,不会出现数据库没起来、游戏进程连阻塞反复重启,最后你还要花时间判断是哪一层出的问题。5.2 查看日志确认服务状态游戏逻辑服务正常启动后,日志里通常会出现一行标志性的记录,比如Server Start Success、listen on 8001等。用下面的命令持续跟踪日志:docker logs -f game_logic --tail 50看到这样的输出时基本不用担心了:[INFO] 2025-01-10 12:00:01 connect mysql success [INFO] 2025-01-10 12:00:01 connect redis success [INFO] 2025-01-10 12:00:02 load config done [INFO] 2025-01-10 12:00:03 game server start on 0.0.0.0:8001如果日志里一直刷connect refused或Auth failed,优先检查数据库和Redis配置,而不是反复重启容器。我最初折腾时就是没注意到Redis密码配置少了一位,结果游戏进程一直在数据库连接成功、Redis鉴权失败之间循环,看起来像卡死,其实原因很简单。5.3 用接口测试验证服务端是否真的能通服务端逻辑进程起来不代表客户端就能连上,还需要验证Web接口层是否正常。这里我习惯用curl做一轮简单的接口冒烟测试。先验证Web首页是否可以访问:curl -I http://127.0.0.1/再验证一个常见的登录接口(具体路径以实际包为准,多数在/api/login或/api/user/login):curl -X POST http://127.0.0.1/api/login \ -H Content-Type: application/json \ -d {account:test,password:123456}如果返回了JSON数据,说明Web接口和数据库的链路是通的。如果返回503或404,则需要检查Nginx站点配置、Web容器日志、数据库连接串这三处地方。还有一种情况:Web接口通,但游戏逻辑服连不上。这种情况通常是逻辑服端口没映射到宿主机,或者监听在127.0.0.1而不是0.0.0.0。用ss -lntp看一下容器内实际监听地址:docker exec game_logic ss -lntp如果监听的地址是127.0.0.1,需要去配置里改成0.0.0.0,否则外部客户端永远连不进来。这是很多人最容易忽略的一个细节。6. 客户端修改与登录实战6.1 Android客户端IP修改与重打包服务端全部就绪后,最后一步就是让客户端连接你的服务器。大部分Android手游客户端都会把服务器IP写在assets资源目录的一个配置文件中,常见文件有assets/config/server.json、assets/bundleinfo等。我惯用的处理流程:用Apktool反编译APK:apktool d shenwang.apk在反编译产物里搜索IP地址或域名:grep -r 192.168\|127.0.0.1\|yourdomain ./修改目标文件里的服务器地址和端口,改成你自己的公网IP或域名重新回编译:apktool b shenwang -o shenwang_new.apk对新APK进行签名签名这一步很关键。系统应用或游戏客户端通常需要签名校验,如果不签名或签名不一致,安装后可能闪退或连接失败。签名命令:keytool -genkey -alias key -keystore game.keystore -validity 3650 -keyalg RSA jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore game.keystore shenwang_new.apk key注意:部分客户端会对包名和签名做合法性校验,一旦被篡改就提示安装包损坏或请从官方渠道下载。碰上这种情况,就要检查客户端是否做了完整性校验。如果校验写在JNI库里,破解成本会高很多,这种情况就超出搭建服务端的范畴了,通常说明这套客户端本来就是给特定设备或渠道用的。6.2 客户端服务端版本号匹配改完IP后,还有一个容易踩的坑:客户端版本号和服务端配置的版本号不一致。游戏启动时,客户端会向服务端请求版本配置,如果服务端返回的版本低于客户端最低版本,就会提示请升级客户端。这个问题通常在服务端配置里可以改:{ client_ver: 1.0.1, min_ver: 1.0.1, update_url: http://你的服务器地址/pack.apk }尽量把客户端自身AndroidManifest.xml里的versionName和服务端配置保持一致,不要随意改动,否则测试时很容易出现拉取更新包失败的尴尬情况。6.3 完整登录链路自测客户端打包安装后,不要急着登录。先在客户端打开前,用电脑或手机浏览器访问服务器IP的80端口,确认Web界面能打开。这一步能帮你快速判断是客户端的问题还是服务端问题。然后打开游戏,观察以下几个节点:启动页能否拉到公告:拉不到公告通常是Web服务或公告接口地址错误输入账号密码后能否进入选服界面:卡在登录说明Web接口或数据库账号验证有问题进入选服/创角界面是否流畅:这一步涉及游戏逻辑服和数据库创建角色后能否正常进入主城:进入后卡加载或秒退,多半是配置的资源路径错误如果整条链路走通,说明服务端搭建成功。接下来就可以做充值、GM后台发道具等进一步测试了。7. 常见问题与排查技巧实录7.1 服务起不来:端口、依赖、日志三板斧服务起不来是最常见的问题。我的排查顺序固定三步:先看端口有没有被占,再看服务依赖是否都正常,最后看容器日志里的具体报错。# 查端口占用 lsof -i:8001 ss -lntp | grep 8001 # 看容器列表与状态 docker ps -a # 看关键日志 docker logs game_logic --tail 100端口被占的话,要么关掉占用进程,要么改服务端配置和Compose映射端口。依赖异常的,用docker inspect game_logic检查环境变量和网络配置。日志报错才是最后要精准定位的点,大部分问题都会在日志里留下直接线索。7.2 数据库连接失败的典型原因数据库连接失败占了这类搭建问题的一半以上。常见原因就这几类:密码错误或用户名不对:docker exec进容器,用配置里的账号密码手工登录测试权限不足:远程登录收不到授权,需要给%通配授权字符集乱码导致SQL执行失败:转换编码后重新导入内存不足导致MySQL自动退出:free -h查看内存,必要时加Swap或升级配置这里有一个实用技巧:在游戏配置里发现的连接串可能是jdbc:mysql://127.0.0.1:3306/shenwang_db,这种写法在容器内启动时指向容器自身的回环地址,而不是MySQL容器。需要改成jdbc:mysql://game_mysql:3306/shenwang_db或宿主机内网IP。一个细小的地址差别,就能让排查陷入僵局。7.3 登录超时/卡在验证界面服务端都正常启动了,但客户端打开后一直转圈、提示服务器连接超时,这个问题我建议按这个顺序排查:客户端里填的IP和端口是否正确,尤其是端口是不是映射后的宿主机端口云主机安全组是否放行了对应端口游戏逻辑服务是否监听在0.0.0.0客户端反编译后重新打包的签名是否正确是否客户端与服务端的加密协议或版本不匹配前四点都比较容易定位,第五点比较麻烦。如果你用官方最新客户端去连一套旧服务端,协议字段不匹配很可能直接握手失败,表现为登录无响应而不是明确的报错。解决办法是寻找和该服务端匹配的历史客户端版本。7.4 资源占用排查与日常维护命令服务端跑起来之后,日常维护也是个体力活。内存泄漏和僵尸进程是这类游戏的常见问题,建议养成定时查看的习惯:# 查看容器资源占用 docker stats --no-stream # 查看宿主机内存和负载 free -h uptime # 清理日志文件,防止磁盘占满 docker system prune -f服务端长时间运行后,如果发现进入游戏越来越卡,优先考虑重启游戏逻辑容器,然后观察内存是否恢复正常。重启命令很简单:docker-compose restart game但要注意:重启会踢掉当前在线的玩家,如果有朋友在玩,最好选维护时间再操作。7.5 常见问题速查表现象可能原因排查方法MySQL容器反复重启内存不足/端口占用free -h, lsof -i:3306游戏进程日志报connect refused连接地址错误/服务未起确认MySQL、Redis容器状态Redis鉴权失败配置密码与实际不一致检查.env和config配置Web接口404Nginx配置路径错误查看web容器日志客户端能打开但选服超时安全组未放行/端口映射错误curl测试游戏端口登录后创建角色失败数据库表缺失/权限不足show tables, grant授权服务端长时间运行后卡顿内存泄漏/日志膨胀docker stats, 定期重启最后说一点个人经验搭建这套回合策略卡牌手游服务端的最大心得,就是耐心分层。把服务端拆成Web、数据、缓存、逻辑四层,每一层单独验证,不要指望一次把所有容器全部拉起来就能成功。我第二次重装系统时因为图省事跳过了一层一层的验证,结果一个数据库字符集问题查了近两个小时,之后老老实实回到分层排查法,反而最快。另外,不管你是自己研究还是和朋友联机,都建议把服务端文件、SQL脚本和客户端APK备份到本地一份,Docker挂载的目录也定期做快照。这类资源在网盘和社群里经常失效,忘了备份等于白折腾一整晚。最后再分享一个小技巧:服务端配置里如果遇到不知道含义的开关,可以先保持默认,只改必改项,跑通了再逐个试功能。一次改太多参数,出了问题反而不知道是哪一项导致的。
