从本地能跑到线上可用：进程守护、反向代理与容器化部署全攻略

凌晨两点多，我负责的服务被 systemd 反复拉起，又反复在几十秒内崩溃。日志里没有报错堆栈，只有一行 "Killed"。那个瞬间我突然意识到，代码在本地跑得飞快，和一台需要 7×24 小时在线稳定的服务之间，差的不是运气，而是一整套还没建立起来的工程习惯。

这篇文章的代号就叫 UP。不单指"把服务跑起来"，更指的是从零开始，把一个服务推到"可用且可持续"的状态。我用一次完整的上线复盘，把裸机准备、进程守护、反向代理、容器化编排、监控告警，再到一次真实线上事故的排查，全部串起来讲清楚。适合刚接触部署的新手，也适合那些总在"本地能跑、一到服务器就翻车"里挣扎的朋友。每一步我会写清楚当时为什么这么选、放弃了哪些方案，以及踩过哪些文档里不会写的坑。

1. 为什么"本地能跑"和"上线可用"之间隔着一条鸿沟

先聊一个最容易被忽视的事实：你在开发机上敲 node app.js 看到监听成功，和用户真的能从公网稳定访问你的服务，中间隔着很多看不见的差异。

1.1 本地环境与生产环境的四个隐形差异

第一个差异是资源约束。我本地开发机 16G 内存，Node 进程可以随便霍霍。可一台 2G 内存的服务器上，Node 默认堆大小是按物理内存比例算的，加上多进程部署，稍不注意就触发 OOM。你以为代码写对了就没事，实际上资源配额变了，行为就是不一样。

第二个差异是运行时长。本地演示二十分钟，和线上连续运行三个月，完全是两个世界。很多问题只会在长时间运行后冒出来，比如内存缓慢增长、文件句柄泄漏、日志文件撑爆磁盘。这些在本地你根本来不及碰上。

第三个差异是并发模型。本地调试时一次就一个请求，线上可能是三百个请求同时进来。你的代码里只要有一处没有做超时控制，或者某个共享变量没处理好，低并发下毫无感觉，高并发时直接崩给你看。

第四个差异是环境本身。时区、locale、底层系统库版本、进程最大文件句柄数、内核网络参数，这些东西不同，可能直接导致时间显示错乱、视频流异常、连接数到达上限后拒绝服务。

我经常用一个类比：在家炒菜和餐厅后厨高峰期出餐是两回事。家里的火候、备菜、节奏都是你说了算；餐厅后厨要考虑几个灶同时开、配菜员忙不过来、洗碗间堆满盘子。上线就是这个逻辑，你的服务要进入一个"随时应对突发客流"的后厨，而不是安静的单人操作台。

1.2 "上线"到底意味着什么：从进程变成服务

在开发机上启动一个进程很简单，前台跑着，Ctrl+C 就停。但"上线"意味着你要把一个普通进程，改造成具备这几个特性的服务：

• 开机自启，服务器重启后服务能自己回来；
• 崩溃后能自动拉起，而不是等人工登录发现挂了；
• 日志有地方存，并且按天或按大小轮转，不会把磁盘写满；
• 以独立用户身份运行，不直接跑在 root 下；
• 配置和代码分离，密钥不藏在源码里。

这些说起来都是常识，但很多人第一次部署时，就是拿着开发环境那一套直接裸奔上线的。我见过不少人，把 node app.js 往 nohup 后面一挂，就认为完事了。SSH 一断，session 一清，进程跟着没。所以后续所有步骤的前提，都是先把"进程"升级成"服务"。

2. 上线前必须补齐的三件套：进程守护、反向代理与环境隔离

这里的三件套，是我认为任何 Web 服务上线都绕不过的基础设施。没有它们，服务即使今天起来了，也活不过下一次重启或者下一次被人扫到端口。

2.1 systemd 不是可选项，是底线

Linux 上最通用的进程守护方案，就是 systemd。我最初也试过用 pm2 去管 Node 服务，确实方便，图形面板也有，但它本身又是一个 Node 进程，还得想办法去守护这个守护者。后来我统一改成 systemd，一台机器上的所有服务都用同样的方式管理，心智负担低很多。

一个最简的 service 文件长这样：

几个关键字段我单独解释一下：

• Restart=always：无论什么原因退出，systemd 都会尝试重启。这是服务在线的基本保障。
• RestartSec=3：重启前的等待时间。太短会陷入崩溃重启的死循环，太长又影响恢复速度，3 秒是我比较常用的值。
• StartLimitIntervalSec 和 StartLimitBurst：配合使用的限流。比如 60 秒内最多重启 5 次，超过就不再尝试，防止服务崩溃时无限刷日志把磁盘写满。
• EnvironmentFile：从外部文件加载环境变量，而不是把密钥写在 unit 文件里。

我踩过最深的坑是权限。有次部署一个静态资源服务，User=deploy 没问题，但 WorkingDirectory 指向的目录属于 root，应用启动后没权限写临时目录，报错是模模糊糊的 "Permission denied"。排查了半天，最后发现目录权限的问题。所以记住三点：目录属主和 User 一致、环境变量文件只允许 deploy 用户读取、可执行文件的路径要写绝对路径。

2.2 Nginx 反向代理：为什么服务不该直接暴露端口

有人觉得，我的服务监听 3000 端口，那服务器安全组放行 3000，用户直接访问 http://ip:3000 不就行了？行是行，但这样会带来一堆问题。

第一个问题是 TLS 证书不好管理。现在有免费的证书申请工具，但证书续期、自动更新，这些逻辑放在 Nginx 这一层统一处理会更简单。第二个问题是安全。直接暴露业务端口，等于把所有端口敞开给扫描器，就算应用本身没有漏洞，也会被各种探测流量骚扰。第三个问题是缓冲和限流。Nginx 可以对上游响应做缓冲，可以在入口做连接数限制、并发限制，这些如果全部塞进应用代码里，既费劲又容易出错。

我常用的 Nginx 配置片段长这样：

需要注意的一点：应用服务监听地址，我建议绑到 127.0.0.1，而不是 0.0.0.0。这样外部无法直接访问 3000 端口，所有流量都必须经过 Nginx。既统一了日志来源，也少暴露一个服务面。

2.3 环境变量：最容易被忽视的安全命门

上线时最容易顺手做错的一件事，就是把数据库密码、第三方 API Key 写在代码文件里，然后推到代码仓库。代码仓库是会流转的，别说外部泄露，光内部同事之间拷贝一份，密钥就扩散了。

我现在的做法是：

• 所有配置通过环境变量注入；
• 每个环境一套独立的 .env 文件，生产环境变量文件权限设为 600，只允许 deploy 用户读取；
• 仓库里只保留 .env.example，里面是占位符和必要的注释；
• 应用启动时读取环境变量，没有关键变量就直接报错退出，而不是用默认值硬跑。

如果你觉得"环境变量会不会太多了"，我的经验是：把数据库连接串、Redis 密码、密钥、域名、日志级别这类"环境相关"的配置全部放进去，代码里一个硬编码都不留。刚开始麻烦，但换服务器、加实例、交接给别人的时候，你会感谢当时的自己。

这里有个小提醒：环境变量文件里如果有特殊字符，比如密码带 # 或空格，在 systemd 的 EnvironmentFile 里要注意转义规则。我见过有人密码里有 #，结果从那个字符开始全被当成注释，应用拿到的数据库密码是错的，排查了很久。

3. 从命令到体系：一套能一键启动的部署方案

三件套搞定后，服务已经能作为 systemd 服务稳定运行了。但项目一旦依赖多个组件，比如一个 Web 服务要配 PostgreSQL 和 Redis，我就开始考虑更完整的方案。

3.1 为什么最终选择 Docker Compose 而不是裸机部署

裸机部署 + systemd 的优点是资源占用小，少一层抽象，排错直接。缺点是依赖环境的一致性全靠维护者的纪律。你在这台服务器上装好了 PostgreSQL 16，另一台新服务器可能默认装的是系统自带的 PostgreSQL 13，行为差异就来了。

Docker Compose 给出的方案是：把应用、数据库、缓存、网络、卷全部用代码描述出来，一个 docker compose up 就把整套环境拉起来。和裸机的对比我总结如下：

对比项	裸机 + systemd	Docker Compose
一致性	依赖运维人员手动维护	镜像固化了运行时环境
依赖编排	手动写启动顺序和等待逻辑	depends_on + healthcheck 自动处理
隔离性	进程共用宿主资源	容器独立，互不污染
资源开销	低，几乎没有额外损耗	有镜像层和容器运行时开销
复杂度	直接用 systemd，心智简单	需要理解镜像、网络、卷的概念

我的结论不是非黑即白。单服务、小内存机器、或者团队对 Docker 不熟，裸机 + systemd 完全够用。但只要服务依赖关系超过两个，或者你打算在多个环境里重现部署，我建议直接上 Compose。它解决的问题不是"跑起来"，而是"换台机器也能跑起来"。

3.2 一份能满足日常项目的 docker-compose.yml 参考

以一个典型的 Web 应用为例，依赖 PostgreSQL 和 Redis。我的 compose 文件结构如下：

几个地方解释一下为什么要这么写：

• ports 绑定 127.0.0.1:3000:3000，而不是 3000:3000。这样外部访问不到容器的 3000 端口，只有本机的 Nginx 能转发进去。
• depends_on 加上 service_healthy 条件，是 Compose 里比较新的语法。相比老版只保证启动顺序，它强制要求依赖容器健康检查通过后，才启动应用容器。
• 每个服务都配 healthcheck。这个很关键，后面监控部分我会详细说，这里先记住：健康检查是编排系统判断服务状态的核心依据。
• 数据库数据放在 named volume 里，保证容器重建后数据不丢。

我实际使用中还遇到过一个细节：Compose 文件里的 $${} 是为了转义 $，避免被 Compose 本身解析，而是留给容器环境去解析。第一次写的时候容易写成 ${REDIS_PASSWORD}，结果 Compose 在宿主机环境变量里找不到，启动直接报错。

3.3 第一次 docker compose up：完整启动顺序与等待策略

第一次启动，我的顺序是这样的：

-d 表示后台运行，--build 会先构建镜像再启动。构建过程可能很久，日志输出密密麻麻，耐心等。构建完成后，Compose 会依次创建网络、数据卷、启动 postgres 和 redis，等待它们健康，然后启动 app。

启动后第一件事是看状态：

如果 app 显示 running，别急着庆祝，先看日志：

我遇到最多的情况是：app 容器启动了，但应用内部连接数据库失败，然后一直循环重试。原因往往是数据库虽然容器起来了，但对外端口的服务还没完全就绪。所以在应用代码里，连接数据库时一定要加重试机制，比如前 10 次连接失败，每次等 1 秒再重试。

服务全部起来后，用 curl 验证本地链路：

两个都返回 200 或 30x，再算真正完成。注意，这里有个很容易忽略的点：docker compose up 一次只是启动，更新代码后的标准操作是 git pull，然后重新 docker compose up -d --build。不要图省事直接用 docker compose restart，那不会重新构建镜像，更新了代码也等于没更新。

4. 保持 Up 的秘诀：监控是给未来的自己买保险

服务上线只是开始，真正难的是让它长期保持 Up 状态。这里说的监控，不是高大上的可观测性平台，而是最基础的三层防线。我建议每个项目至少做到这三件事。

4.1 外部 uptime 检查：最简单的第一道防线

很多人以为，服务部署好后，自己写个脚本每分钟 curl 一下就行了。问题是：检查进程在服务器本机执行，一旦整台服务器挂了、网络出问题了，本机检查根本发现不了，因为检查脚本也一起挂了。

所以要有外部监控，用另一台机器或第三方服务发起请求。最简单的方案，可以是自建一个监控服务，比如 Uptime Kuma，它是 Docker 单容器应用，建好后添加一个 HTTP 监控项，目标填你的公网地址，告警方式可以选 Webhook、邮件、Telegram Bot 等。

如果不想再引入一个服务，用 cron 写个脚本也可以：

注意几点：检查请求一定要带超时，否则 curl 会一直挂着；检查内容不能只看返回码，最好能解析一下响应体，防止返回了一堆错误但状态码还是 200 的情况。

4.2 健康检查端点：别只检查"进程还活着"

外部监控通常只检查服务能不能响应，但"能响应"不等于"健康"。比如数据库连接池已经满了，应用还能返回 200 吗？很可能不会，但有时会因为代码写得不好，在错误处理时依然返回 200。

所以我都会为服务专门加一个 /healthz 端点，它的逻辑是：

这个端点会主动检查应用赖以生存的关键依赖，比如数据库、缓存。依赖没问题返回 200，有问题返回 503。这样外部监控和容器编排系统拿到的不再是"进程还活着"这个最低限度的信息，而是"服务现在能不能真正处理请求"。

当然，健康检查也别过度设计。不要在这个端点里递归检查所有下游依赖的下游，否则一次依赖抖动可能导致级联报警。检查你最核心的一两个依赖就足够。

4.3 资源水位与日志轮转：死在黎明前的两种常见方式

监控里最容易被忽略的资源是什么？我一直觉得是磁盘。服务器运行一年半载，最容易出的事不是 CPU 跑满，而是日志文件悄悄把磁盘写满，然后数据库、应用全部开始报错。香港那边有句老话叫"识睇戏"，运维也一样，要学会看水位线。

基础资源指标我至少会盯这几个：

指标	命令/工具	告警阈值参考
CPU 负载	uptime / top	长期超过核数的 70% 需注意
内存	free -h	可用内存长期低于 10% 需排查
磁盘使用率	df -h	超过 80% 就应清理或扩容
日志增长率	du -sh /var/log	单日增长超过 1G 需关注

日志轮转是必须提前配置的。以 systemd 服务输出到 /var/log/myapp/ 为例，logrotate 配置如下：

含义是：按天轮转，保留 14 份，压缩旧日志，单份日志超过 200M 也会提前触发轮转，新文件属主为 deploy 用户。

很多服务挂掉之前，其实已经给了你足够多的预警信号，只不过没人看。磁盘涨到 90% 没人管，内存持续升高没人管，连接数到达上限没人管，最后某个早上爬起来发现全站打不开，才开始满世界找日志。监控不是仪式感，是保险。买不买是你的选择，但出事的时候别抱怨保费贵。

5. 运营稳定后的第一场事故：从 502 到连接池耗尽的完整排查

讲完了预防，再讲一个真实的事故复盘。这个案例不是虚构的极端场景，而是很多服务上线后都会遇到的典型问题：流量稍微一涨，数据库连接先撑不住。

5.1 现象：高峰时段全线 502

服务上线大约第 12 天，下午三点多，陆续有用户反馈页面打不开。我自己打开页面，先是白屏转圈，然后出现 502。

注意，这里有个很有意思的细节：看服务器状态，Nginx 是活的，应用进程是活的，curl http://127.0.0.1:3000/healthz 偶尔能通，偶尔超时。如果你只盯着进程活没活，会觉得"一切都正常"，但用户端体验已经崩了。

Nginx 的错误日志里出现大量这样的记录：

我当时的判断是两步：先确认是不是大规模故障，然后尽快把服务状态拉回可用。但因为应用还在，还不能简单重启解决，得找到根因。

5.2 排查链路：从 Nginx 日志一路摸到数据库

排查的顺序我按这条链路走，每一步都用数据排除一个方向：

第一步，看基础状态。执行 free -m、df -h、uptime，发现内存还有余量，磁盘没满，负载不高。这说明不是资源耗尽导致的整体故障。

第二步，看应用日志。发现大量类似 ConnectionAcquireTimeoutException 和 Request timed out 的错误。到这里，方向已经指向数据库连接获取超时。

第三步，查 PostgreSQL。登录执行 SHOW PROCESSLIST;，结果让我意外：大量连接处于 Sleep 状态，而且 max_connections 显示为 500，当前连接数已经逼近上限。也就是说，数据库连接被占满了，新的查询根本拿不到连接。

为什么连接会被占满？继续看，发现应用里配置的连接池太大，单实例 max 配置了 200，而我当时跑着 2 个应用实例，加起来最多 400 个连接。再加上有些慢查询执行时间超过 30 秒，连接迟迟不释放，积压越来越多，最终把数据库连接消耗殆尽。

5.3 根因与修复：连接池、慢查询与超时设置

根因链条很清楚：连接池参数不合理 + 慢查询积压 + 连接获取超时设置过长，三者叠加，导致数据库连接被耗尽。

我当时在应用里用的是 PostgreSQL 连接池，修正后的配置参考如下：

几个参数的含义：max 是池里最多保持多少个连接；idleTimeoutMillis 是空闲连接多久被回收；connectionTimeoutMillis 是如果拿不到连接，最多等多久就报错；maxUses 是连接被复用多少次后强制替换，防内存泄漏。

关于连接池大小的计算公式，我后来一直记着这个原则：连接池上限应该远小于数据库 max_connections，而且要留出余量。比如数据库 max_connections=500，部署 2 个实例，那每个实例 max 设在 20 左右已经非常宽裕了，因为通常应用同时在处理的事务数远没有那么多。真正的瓶颈是查询效率和事务长度，而不是连接数量。

数据库侧，我查到了两条慢查询，都是全表扫描，正好卡在业务高峰期频繁执行。补上合适的索引之后，查询耗时从几百毫秒降到几十毫秒，连接持有时间大幅缩短。

Nginx 侧也顺手调整了 proxy_read_timeout，从默认值压到 60 秒。这个值之前设得太长，导致只要数据库卡住，Nginx 就一直等，用户的浏览器也在无限转圈。现在最多等 60 秒就返回 504，用户和运维都能更快感知到异常。

5.4 压测验证与预防措施

修复之后，我没有直接宣布完事，而是做了一次简单的压测验证。用 ab（ApacheBench）跑一轮，逐步增加并发数：

-c 100 表示模拟 100 个并发请求。压测过程中我同时开了一个终端监控数据库连接数：

观察到连接数稳定在几个到十几个，不再飙升，响应时间和错误率都回到正常水平，这才确认修复生效。

后来我把预防措施固化成了三项：应用设置连接池上限时，先算好数据库总容量；上线前的压测环节不能省，至少要模拟平时峰值的 1.5 到 2 倍流量；监控告警里要加上数据库连接数这个指标，超过阈值就通知。那次事故之后，我把连接池参数写进了部署检查清单的第一页。以后每次新服务上线，压测环节都不敢再跳。把服务拉起来只是完成了一半，另一半是确认它能在最坏情况下，依然稳稳地待在 Up 状态。