企业官网建设流程全解析

“私人服务器”这四个字在技术圈里意思其实很单纯：把原本跑在别人机房里的那套服务，搬到自己能摸得着的机器上跑一遍。这几年我帮人搭过不少自托管环境，从自建笔记同步到局域网里的游戏后端，被问得最多的一类问题就是“5分钟上手：零代码打造明日方舟私人服务器”这种标题到底靠不靠谱。我的答案分两半：部署动作确实能在几分钟内跑完，但前提是你清楚自己在搭什么、边界在哪里、出问题该往哪儿看。

先把边界说清楚。客户端里的通信协议、美术资源、数值配置都属于权利方，私自对外提供服务是明确的侵权行为，也不在本文讨论范围内。我下面写的内容，全部基于自建的测试服务端和自有资源，跑在断开外网的本地环境里，纯粹做架构学习用。我聊的是服务端工程实践：容器编排、反向代理、数据库初始化、日志排查这一整套东西。游戏名字在这里只是一个引子，真正值钱的是这套工程方法。

如果你是后端新手，想找个“麻雀虽小五脏俱全”的练手项目，这套东西非常合适——它同时涉及 HTTP、WebSocket、数据库、缓存、静态资源分发、反向代理，比大多数教程里的增删改查示例真实得多。如果你是有几年经验的运维，把它当成一次容器化改造的复盘看也不亏，里面关于卷挂载权限、时区错乱、健康检查的坑，我基本都踩过一遍。

1. 先把“私人服务器”这件事拆开看

1.1 游戏服务端的四个真实组成部分

很多人以为服务端就是一个程序，双击打开就完事。实际拆开来看，一个能跑起来的游戏后端至少包含四层，缺一层都跑不通。

第一层是网关层，负责接收客户端请求、做路由分发、维持长连接。第二层是业务层，处理登录、编队、关卡结算这类逻辑。第三层是数据层，通常是一个关系型数据库加一个缓存，存玩家存档、配置表、会话状态。第四层是资源层，负责把静态资源文件按路径分发给客户端。

这四层的意义在于：它们是可以分别部署、分别重启、分别排查的。我第一次搭的时候把所有东西塞进一个容器，结果数据库挂了要连带重启整个服务，日志混在一起根本没法看。后来改成按职责拆分，虽然容器数量上去了，但排障效率提升非常明显——哪个环节报警就动哪个，其他部分不受影响。

对新手来说，理解这个分层比记住任何一条命令都重要。因为后面所有的配置文件、端口映射、卷挂载，本质上都是在描述这四层之间怎么通信。

1.2 “零代码”这三个字的真实含金量

标题里写“零代码”，这话不算骗人，但得加个注解：零代码指的是不写业务逻辑代码，不是说不写任何配置。

实际动手时你会发现，你要写的东西是一堆 YAML 和配置文件。YAML 这东西看着像配置文件，实际上就是代码，缩进错一个空格整份文件就跑不起来。我见过不少人卡在“服务起不来”，折腾两小时最后发现是services:下面的缩进用了四个空格而不是两个。

所以更准确的说法是：零业务代码，配置即代码。你不需要会写 Java、Go 或者 C#，但你需要理解“声明式”这个思路——你不是在命令机器“先做这个再做那个”，而是在描述“我最终要一个什么样的状态”，然后让工具自己去收敛。

这个思维转换是新手最容易卡住的地方。举个例子：传统做法是先创建目录，再拉镜像，再启动进程，三步依次执行；声明式做法是写一份文件说明“我要三个容器、各自挂哪个目录、互相怎么连通”，然后一条命令下去，工具自己判断该拉什么、该建什么。理解了这个，后面看编排文件就不会一头雾水。

1.3 边界清单：哪些事我坚决不做

动手之前先划三条线，能省掉后面很多麻烦。

• 不碰客户端。任何形式的客户端改动、协议劫持、证书替换，我都不建议碰。一是法律风险，二是技术上极其脆弱，客户端一更新全白干。
• 不对外网开放。所有测试只在局域网内或者本机回环地址上进行，路由器上不做端口映射。开放到公网意味着你要面对扫描、撞库、DDoS，那是一个完全不同的工程量级。
• 不做资源分发。资源文件只用自己造的测试素材，不收集、不传播任何受版权保护的内容。

把这三条守住，剩下的事情就是纯粹的技术练习。我在实际项目里也一直用这个标准来要求自己：先把环境画个圈，圈里随便折腾，圈外一步不迈。

2. 方案选型：为什么我把容器化排在第一位

2.1 物理机、虚拟机、容器三条路的成本对比

搭建本地服务端，部署方式无非三条路。我做过一个粗略对比，用的是同一台四核八线程、16G 内存的旧笔记本，结论很清晰。

物理机直装的问题是污染不可逆。各种依赖装进系统盘，版本冲突了只能重装系统。我最早就是这么干的，装完之后系统里躺着一堆不知道干什么用的运行库，后来想清理又不敢动。

虚拟机解决了污染问题，但每次重建都要走一遍系统安装流程，十几分钟起步，而且虚拟机本身要吃掉一大块内存。对于本来就只有 16G 内存的家用机器，留给服务端的内存就更紧张了。

容器是折中方案：镜像层负责环境一致性，容器层负责运行隔离，重建只需要删掉容器重新起一个，数据都在卷里不会丢。这条路上手成本略高，但一旦跑通，后面的迭代速度完全不是一个量级。

2.2 选 Docker Compose 而不是 K8s 的理由

既然决定容器化，下一个问题是要不要上 Kubernetes。我的答案很明确：单机场景不要。

K8s 解决的是“几十台机器上跑几百个服务”的问题，它带来的调度、自愈、滚动更新能力，在单机上全是负担。你要额外维护一套控制平面，光 etcd 就要吃几百兆内存，配置文件复杂度翻好几倍。我试过一次，为了跑三个容器搭了一套单节点 K8s，结果光是排查网络插件的问题就花了一整天，正经的服务反而没怎么碰。

Docker Compose 的定位刚好相反：它就是为“一台机器上跑几个互相有关系的容器”设计的。一份 YAML 描述所有服务，一条docker compose up -d全部拉起，网络自动创建，服务名直接当主机名用。对个人项目和中小规模自托管，这就是甜点区。

提示：如果你后面真的需要多机部署，Compose 的配置文件迁移到 K8s 的成本远低于从零开始设计。先从简单的来，不要提前优化。

2.3 硬件与带宽的估算过程

硬件需求可以按组件逐个累加估出来，不需要靠猜。

服务端主进程常驻内存在 300 到 500MB 之间，波动主要来自并发连接数。数据库按 200MB 算，缓存按 64MB 算，反向代理 30MB 左右，再加上系统和其他杂项预留 1GB。累加下来大概是 1.6 到 1.8GB，为了留出编译和临时峰值空间，我按 2 倍余量配，得出最低 4GB 内存这个结论。

CPU 方面，单机自用基本不构成瓶颈，双核足够，四核更从容。真正影响体验的是磁盘，因为数据库写入和日志刷盘都吃 IO。机械硬盘跑数据库会让首次启动的初始化时间从几秒变成几十秒，建议直接上固态。

带宽反而是最容易被高估的项。局域网内测试，流量只有几百 KB/s 级别，千兆内网完全是浪费。真正要关注的是端口规划，这个下面单独讲。

3. 宿主环境准备：从裸系统到能跑容器

3.1 系统版本与内核参数调整

宿主系统我一般选长期支持的服务器版发行版，桌面版也行，但记得关掉休眠和自动更新——半夜自动重启把服务干掉这种事我遇到过两次，之后所有测试机第一件事就是处理更新策略。

内核参数主要调两个方向。一是文件描述符上限，长连接场景下默认的 1024 很容易打满，调到 65535 比较稳妥。二是端口回收速度，大量短连接会导致 TIME_WAIT 堆积，适当开启端口复用能缓解。

# 查看当前文件描述符上限 ulimit -n # 临时调整（当前会话生效） ulimit -n 65535 # 永久生效需要写入 /etc/security/limits.conf # 并在 systemd 服务配置里同步设置 LimitNOFILE

注意最后一句：limits.conf只对登录会话生效，systemd 管理的服务不读这个文件，得单独在服务单元里加LimitNOFILE=65535。我第一次调完发现容器里的上限还是 1024，查了半天才反应过来是这条。容器进程继承的是 dockerd 的限制，所以还得改 dockerd 的 systemd 配置。

3.2 安装容器运行时

安装方式各发行版不同，这里不逐条列举，只说几个通用注意点。

第一，不要用系统仓库里的老版本。某些发行版自带的容器运行时版本落后好几个大版本，Compose 的语法支持不全，会莫名其妙报语法错误。建议走官方仓库。

第二，镜像加速要配。默认镜像仓库在国外，拉取速度慢且容易超时。配一个可用的镜像加速地址能让首次拉取从十分钟缩短到一分钟内。注意事项是：加速地址只影响拉取，不影响推送和完整性校验，可以放心配。

第三，验证安装。装完之后跑一句docker run --rm hello-world，能正常输出就说明运行时、网络、存储驱动都没问题。这一步别跳过，我见过装了但存储驱动选错的，后面卷挂载全部失败，排查起来很绕。

# 安装后验证 docker version docker compose version docker run --rm hello-world # 检查存储驱动（推荐 overlay2） docker info | grep -i storage

3.3 目录结构与权限规划

这一步很多人随手就过了，后面全是苦头。我的习惯是在一个固定位置建一个项目根目录，下面按用途分几个子目录。

mkdir -p /opt/selfhost/{config,data,logs,backup}

config放所有配置文件，data放数据库和持久化数据，logs单独挂出来方便排查，backup放备份产物。

权限方面有个硬性要求：容器内进程的 UID 必须对宿主目录有写权限。很多官方镜像为了安全会用非 root 用户运行，UID 通常是 1000 或者 999，如果你把宿主目录设成 root 独占，容器写日志就会报 Permission denied。

我在这个问题上栽过不止一次。最稳妥的做法是提前查清镜像的默认 UID，然后把宿主目录的属主改过去：

# 假设镜像以 UID 1000 运行 chown -R 1000:1000 /opt/selfhost/data chmod -R 750 /opt/selfhost/data

如果暂时不确定，先用777跑通验证链路，确认无误后再收窄权限。先用宽松权限验证、再收紧，比反过来省时间——因为权限问题的报错往往不直观，容易误判成别的原因。

4. 编排文件逐段拆解

4.1 服务拓扑与端口规划

端口规划的本质是回答“谁访问谁”。我的原则是：内部通信用容器网络，外部访问只暴露一个入口。

也就是说，数据库、缓存这些组件完全不映射到宿主端口，只在容器网络内部通过服务名互相访问。宿主上只暴露一个反向代理端口，所有外部请求都从这里进来，由它转发到具体服务。

这张表看着简单，但它决定了后面所有的网络配置。好处很直接：外部攻击面只有一个端口，数据库就算有弱口令也暴露不出去。

4.2 compose 文件骨架与逐行注释

下面是我用了很久的一个骨架，改动不多，结构稳定。

services: proxy: image: nginx:stable-alpine ports: - "8080:80" volumes: - ./config/nginx.conf:/etc/nginx/nginx.conf:ro depends_on: - app restart: unless-stopped app: image: your-backend-image:latest environment: - DB_HOST=db - DB_PORT=5432 - CACHE_HOST=cache - TZ=Asia/Shanghai volumes: - ./config/app.yaml:/app/config.yaml:ro - ./logs:/app/logs depends_on: db: condition: service_healthy restart: unless-stopped db: image: postgres:16-alpine environment: - POSTGRES_PASSWORD=change_me_please - TZ=Asia/Shanghai volumes: - ./data/pg:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 5 restart: unless-stopped cache: image: redis:7-alpine command: ["redis-server", "--appendonly", "yes"] volumes: - ./data/redis:/data restart: unless-stopped

几个关键点单独说。

depends_on配condition: service_healthy这件事必须做。默认的depends_on只保证容器启动顺序，不保证服务可用。数据库容器起来了但还没初始化完，业务服务就去连，直接报连接拒绝然后退出。加了健康检查条件之后，编排工具会等数据库真正可连了才启动业务容器。

restart: unless-stopped基本是标配。它保证宿主机重启、进程崩溃之后服务能自己回来，同时你在手动停止之后它不会自动拉起，符合直觉。

TZ环境变量必须设。不设的话容器默认走 UTC，日志时间比本地时间差八小时，排查问题时对不上号，会浪费大量时间。

4.3 数据卷和配置挂载的坑

卷挂载分两类：绑定挂载（bind mount，宿主路径直接映射到容器内）和命名卷（named volume，由工具管理存储位置）。

我的选择是：配置文件用绑定挂载，方便随时改随时生效；数据目录用绑定挂载，方便备份和迁移；只有那些不需要我直接操作的数据用命名卷。

坑主要在绑定挂载上。第一个坑是路径必须用绝对路径或者./开头，写成config/app.yaml会被当成命名卷处理，创建一个空卷挂上去，然后你会发现配置文件“消失了”。

第二个坑是单文件挂载的 inode 问题。把宿主的单个文件挂进容器时，如果宿主上是用编辑器保存（很多编辑器保存时会新建文件再重命名），容器里看到的还是旧 inode，内容不更新。表现就是“改了配置重启没生效”。解决办法是改完配置之后重启容器，或者干脆挂载整个目录。

第三个坑是:ro只读标记。配置文件我强烈建议加:ro，防止容器内进程误写。数据库目录绝对不能加:ro，否则初始化直接失败。

4.4 环境变量与启动参数

环境变量和启动参数的区别要分清：环境变量影响进程内的配置读取，启动参数覆盖镜像的默认命令。

密码这类敏感信息不要在 YAML 里明文写。虽然有各种密钥管理方案，单机场景下最简单的做法是放在一个.env文件里，YAML 中引用变量名。

# .env 文件，权限设为 600 DB_PASSWORD=换成你自己的强密码 ADMIN_TOKEN=随机生成的长字符串

# compose 中引用 environment: - POSTGRES_PASSWORD=${DB_PASSWORD}

注意.env文件要加到.gitignore里，别连着密码一起提交。这个低级错误我在别人的仓库里见过不止一次。

启动参数方面，缓存服务通常需要显式开启持久化，否则重启之后会话全丢，表现为“用户莫名其妙被登出”。上面骨架里的--appendonly yes就是干这个的。

5. 首次启动与配置调优

5.1 配置文件关键字段逐条说明

业务服务的配置文件通常包含几大块：服务监听、数据库连接、缓存连接、日志、安全。

服务监听部分要关注绑定地址。容器内必须绑0.0.0.0，绑127.0.0.1的话容器外部根本连不进来。这个坑很经典，我第一次配的时候看到日志显示“服务已启动”，但代理一直报 502，查了半小时才发现绑定了回环地址。

数据库连接部分，主机名直接写服务名（比如db），端口写容器内端口，不要写宿主映射端口。这是容器网络的基本规则：同一网络内的容器用服务名互相解析，走的是内部网络，跟宿主端口无关。

日志部分建议配置分级和切割。开发调试时开debug，稳定运行后切info，不然日志文件一天能涨到几个 G。切割按大小或者按天都行，保留最近七份足够。

安全部分至少配两项：接口访问令牌和请求频率限制。哪怕只在局域网用，也建议配上，因为局域网里同样可能有扫描行为。

5.2 数据库初始化与迁移

数据库初始化最容易出问题的地方是初始化脚本只跑一次。大多数数据库镜像的行为是：数据目录为空时执行初始化，数据目录非空时直接跳过。这意味着你改了初始化脚本，重启容器不会重新执行。

我第一次遇到这个情况时完全没头绪，改了脚本、重启、数据还是老样子。后来才明白得先停容器、删掉数据目录、再启动。当然，这只在测试环境可行，有数据的环境必须走正式的迁移流程。

# 测试环境重建数据库（会丢数据，谨慎） docker compose stop db rm -rf ./data/pg docker compose up -d db

生产化的做法是用迁移工具管理表结构变更，每次变更一个版本文件，按顺序执行并记录已执行版本。这套机制能保证多环境一致，也能回滚。对一个练手项目来说可能有点重，但如果你想往真实项目靠，这一步早晚要补。

5.3 反向代理与本地域名解析

反向代理的作用是把一个端口的不同路径分发到不同后端。配置本身不复杂，难的是请求头传递。

server { listen 80; server_name game.local; location /api/ { proxy_pass http://app:8000/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

注意proxy_pass末尾的斜杠。带斜杠和不带斜杠的转发路径完全不同：http://app:8000/会把/api/去掉，后端收到的是/xxx；不带斜杠http://app:8000会保留/api/前缀。这个差异坑过很多人，表现为后端一直返回 404。

本地域名解析，最省事的办法是改宿主机的 hosts 文件，把game.local指到127.0.0.1。不折腾 DNS 服务，够用就行。

5.4 健康检查与日志分级

健康检查的价值在编排里体现得最明显。除了数据库，业务服务本身也应该配健康检查，检查一个专门的健康接口。

healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8000/health"] interval: 30s timeout: 5s retries: 3 start_period: 60s

start_period这个参数很关键。业务服务启动后可能需要几十秒预热（加载配置、建连接池），这段时间内的失败不应该计入重试次数，否则容器会被误判为不健康然后反复重启。我一开始没设这个，服务明明能跑，却被判成不健康无限重启，日志里全是启动记录。

日志方面，统一用docker compose logs -f 服务名看实时输出，配合--tail限制行数避免刷屏。长期日志靠宿主目录挂载出来的文件，用系统自带的日志切割工具管理。

6. 联调排查：连不上到底卡在哪一层

6.1 请求链路的五层定位法

连不上的时候最忌讳瞎试。我固定按五层顺序排查，每次都能快速定位。

第一层，客户端到代理。用curl -v直接打代理端口，看能否建立 TCP 连接。不通说明端口没映射或者防火墙拦了。

第二层，代理到后端。看代理的错误日志，502 表示连不上后端，504 表示后端超时。这两个错误指向的问题完全不同。

第三层，后端到数据库。进后端容器执行连接测试，确认服务名能解析、端口能通、密码正确。

第四层，数据库本身。看数据库日志有没有启动完成，用命令行工具连进去执行一条查询。

第五层，配置是否生效。进容器cat一下挂载进去的配置文件，确认内容是你改过的那份。

这个顺序的底层逻辑是：沿着请求方向逐跳验证，每一跳确认通了再往下走，不要跳着猜。我见过太多人一上来就怀疑代码，最后发现是端口没映射。

6.2 典型故障现象对照表

这张表我贴在显示器边上用了很久，八成问题能在三十秒内定位。

7. 常见问题速查与实战避坑

7.1 容器起来就退出

最典型的原因是配置文件有语法错误。YAML 的缩进、冒号后的空格、特殊字符转义，任何一处不对都会导致启动失败。

排查顺序：先看容器日志，通常会有明确的错误行号；如果日志什么都没有，说明是镜像层面的问题，用docker run -it 镜像名 sh手动进容器试跑启动命令。

还有一种情况是启动命令不存在。自定义镜像或者精简镜像里可能没有 bash，只有 sh，CMD里写bash会直接失败。换成sh就好。

7.2 端口占用与转发失效

port is already allocated这个报错说明宿主端口被占用了。查占用进程：

# 查谁占用了 8080 ss -lntp | grep 8080 # 或者 lsof -i :8080

常见占用者包括：之前没清理干净的旧容器、宿主上装的其他服务。处理方式是换端口或者停掉占用者。

还有一种更隐蔽的情况：容器内服务监听在127.0.0.1而不是0.0.0.0。端口映射是从宿主转发到容器的网卡上，如果进程只绑回环，映射就失效。表现是宿主上curl localhost:8080连接拒绝，但容器内curl localhost:8000正常。

7.3 时间戳与时区错乱

症状是日志时间、数据库记录时间都比实际时间差八小时，或者定时任务在错误的时间触发。

根因是容器默认使用 UTC。解决办法是在环境变量里设TZ=Asia/Shanghai，同时宿主机的时区也要对，因为宿主的时钟是容器时间的来源。

# 检查宿主机时间 date timedatectl status # 容器内验证 docker exec -it 容器名 date

注意有些镜像不带时区数据，设了TZ也没用，得额外挂载宿主的时间区域文件：

volumes: - /etc/localtime:/etc/localtime:ro

7.4 数据卷权限与文件属主

前面提过，这里补充完整排查路径。

症状是容器日志里反复出现Permission denied，或者数据库启动时报could not change directory。

第一步，确认容器内运行的 UID：

docker exec -it 容器名 id

第二步，确认宿主目录的属主：

ls -ln /opt/selfhost/data

第三步，二者对齐。注意用ls -ln而不是ls -l，加了-n才显示数字 UID，光看用户名可能对不上。

注意：不要图省事直接把目录设成 777。宽松权限只能解决表面问题，真正的对齐方式是改属主。而且 777 在某些容器里会被安全策略拒绝。

8. 备份、迁移与后续可扩展方向

8.1 三份备份策略

数据这东西，丢一次就够记一辈子。我的策略是保留三个层级。

热备，每天一次数据库导出，保留最近七天。用数据库自带的导出工具，导出成 SQL 文件，压缩后放backup目录。这个可以在宿主上用定时任务自动跑。

冷备，每周一次整个数据目录打包，保留最近四份。冷备的好处是完全不依赖数据库在运行，恢复速度快。

# 冷备示例 tar -czf /opt/selfhost/backup/data-$(date +%Y%m%d).tar.gz \ -C /opt/selfhost data

离线备，每月一次把冷备文件拷到另一块物理磁盘或者移动硬盘。离线备的意义是防勒索、防误删。云备份当然更好，但那要考虑数据合规，自己搭的环境还是物理隔离最踏实。

三个层级的共同点是：备份文件必须验证可恢复。我见过太多人每天备份，真出事的时候发现备份文件是空的或者损坏的。每个月挑一份恢复一次到测试环境，这个习惯值一百份备份文件。

8.2 迁移到新机器的完整步骤

迁移这件事看起来复杂，按容器化的思路走其实只有四步。

第一步，新机器装好容器运行时，版本尽量和旧机器一致。版本差异过大会导致镜像不兼容。

第二步，把整个项目目录拷过去，包括config、data、docker-compose.yml。注意data目录里的文件属主要保持一致，拷过去之后检查一遍。

第三步，新机器上执行启动命令。因为配置和数据都在，理论上起来就能用。

第四步，改客户端指向新地址，验证功能。

最容易出问题的是第二步的文件属主。用cp -a或者rsync -a保留属主信息，别用不带参数的cp。另外，如果新旧机器的 UID 分配不同（比如旧机器上是 1000，新机器上 1000 是别的用户），要么改文件属主，要么在新机器上创建对应 UID 的用户。

8.3 还能往哪些方向扩展

环境跑通之后，其实还有很多可以往下做的方向，每一个都是独立的学习点。

做一套自动化备份和恢复演练。写个脚本，每月自动从备份恢复到临时容器验证一次，跑完删掉容器，只留下报告。这个练习涉及定时任务、容器生命周期管理、结果校验，很实用。

加一层监控。最轻量的做法是定时请求健康接口，失败就发通知。重一点可以上指标采集和可视化，观察内存、连接数、请求延迟的变化曲线。有了曲线之后你会发现很多平时感知不到的问题，比如内存缓慢增长。

做配置版本管理。把config目录纳入版本控制，每次改配置都留记录。配合提交信息，能回溯任何一次配置变更。这个习惯在出问题的时候价值极高——改了什么、什么时候改的、为什么改，一目了然。

尝试横向拆分的思路。把业务服务和资源服务拆到不同机器，用反向代理做统一入口。这会有新的问题冒出来：跨机网络、配置同步、数据一致性。这些问题在单机上遇不到，但理解了它们，你对分布式系统的认知会完全不一样。

我个人在实际操作中的体会是：整套东西真正难的不是某一条命令，而是建立一套稳定的排查顺序和边界意识。命令记不住可以查，但“先看哪一层、先排除什么”这个判断力，只能靠一次次踩坑积累。你的第一个环境大概率会出各种各样的问题，别慌，那才是真正开始学的时候。