入门级云服务器的文章大多停在"开好机器、装上 WordPress"这一步。但真正要长期在线跑业务，卡住的地方从来不是安装，而是三件事：资源到底怎么分（2G 内存、40G 系统盘、3M 带宽各自的真实上限），发布怎么回滚（出了事故 30 分钟内能不能回到上一个已知良好状态），以及暴露面怎么收（公网机器上哪些端口该开、哪些防护该有）。
本文以一台 2 核 2G / 3M 固定带宽不限流量 / 40G ESSD Entry 云盘 的实例为基线，把"能装起来"到"敢长期用"之间的工程细节逐层拆开。文中配置项和操作路径都是普适做法，实例规格以活动页说明为准。
一、先做资源基线：2G 内存与 3M 带宽的真实上限
不先算账，后面所有选型都会变成碰运气。三个维度需要提前定预算。
内存：2G 是这条线的硬约束。一个可用的最小组合大致是这样——Nginx 常驻 10–30MB，PHP-FPM 按 4 个 worker、每 worker 30MB 估算约 120MB，MySQL 若把 innodb_buffer_pool_size 压到 256–512MB，加上系统与日志服务，峰值会逼近 1.5G。留 200–300MB 给缓存和突发，再配 1–2GB swap 兜住瞬时尖峰。取舍很明确：同机跑数据库就要接受更小的缓冲池与更保守的并发，否则按第五节的路径把库搬出去。
磁盘：40G 里真正会被悄悄吃掉的不是代码，而是日志与镜像。建议在部署前就分区规划：系统与软件约占 10–15G，/var/lib/docker 单独给 10G，业务数据与备份留 10G 以上。容器镜像、journald 日志、Nginx 的 access log 三者都要设上限（docker system prune 定时任务、SystemMaxUse、logrotate 按天轮转并保留 14 份），否则 40G 会在某次发布后突然告警。
带宽：3M 固定带宽不限流量，意味着峰值约 375 KB/s 的出口速率，但月度总量不设限。这决定了策略——页面主体和接口走这台机器，图片、视频、静态资源交给对象存储或 CDN，否则单个并发下载就能把出口占满。按平均页面 300KB 估算，3M 出口能同时服务十余个页面请求；再往上要靠缓存（proxy_cache 或页面静态化），而不是加带宽。
| 资源项 | 规划建议 | 需要盯住的指标 |
|---|---|---|
| 内存 2G | 应用 + 数据库同机时缓冲池控制在 512M 内，配 1–2G swap | free -m、OOM 次数、swap 换入换出 |
| 磁盘 40G | 系统/容器/数据分层，日志与镜像设上限 | df -h、镜像与日志目录体积 |
| 带宽 3M | 静态资源外置，开缓存，限制单连接下载 | 出口速率、5xx 与超时率 |
二、软件栈与容器化的边界
小规格机器上，Docker 的价值不是"隔离"，而是发布版本可回滚：镜像是不可变产物，回滚就是把 compose 里的镜像 tag 换回上一个。代价是额外几十到上百 MB 内存和一些磁盘。判断标准：需要频繁发布、或同机跑多个运行时服务，容器化划算；单站点静态托管则裸装 Nginx 更省资源。
一套可用的 compose 结构大致如下：
services:
nginx:
image: nginx:stable
ports: ["80:80", "443:443"]
volumes:
- ./conf:/etc/nginx/conf.d
- ./certs:/etc/nginx/certs
restart: unless-stopped
mem_limit: 128m
app:
image: <your-app>:<tag>
environment:
- TZ=Asia/Shanghai
restart: unless-stopped
mem_limit: 512m
healthcheck:
test: ["CMD", "curl", "-f", "http://127.0.0.1:8080/health"]
interval: 30s
retries: 3
两个容易漏的点：一是每个服务显式 mem_limit，防止单服务内存泄漏拖垮整机；二是给应用加 healthcheck，让反向代理的失败重试有依据，而不是靠肉眼判断"好像挂了"。
三、发布流水线：三条路径，按团队规模选
路径 A（个人/小项目）：仓库里 git pull 后 docker compose up -d --build。优点是零额外基础设施；缺点是机器上要有构建环境，构建期间 CPU 会被抢。
路径 B（单机生产更稳）：在 CI 里构建镜像推到镜像仓库，机器上只做 docker compose pull && up -d。机器不需要编译工具链，发布耗时也从分钟级降到十几秒，回滚只需改 tag。
路径 C（需要零停机）：Nginx 做上游双端口蓝绿——新版本先在备用端口起容器，健康检查通过后切换 upstream 并 nginx -s reload，旧容器保留一段时间便于快速回退。
TLS 终止放在 Nginx 层，证书用 ACME 自动签发并配置续期后的 reload 钩子。这类问题通常不是配置错，而是"续期成功了但 Nginx 没重载"，所以续期任务之后必须带一步 reload，并配一个证书过期天数的监控告警。
四、公网机器的安全边界
一台挂在公网上的机器，默认假设是"每天都有扫描器在敲门"。收敛顺序建议如下：
- 安全组最小化：只放 22（或改后的 SSH 端口）、80、443。数据库、缓存、管理后台一律不对公网，走内网或 SSH 隧道。
- SSH 加固：密钥登录、禁用密码、禁 root 直登、失败次数限制。这一步做完，绝大多数暴力破解尝试会直接失效。
- 主机层防护：系统与软件补丁及时打、配置基线定期体检（弱口令、异常开放端口）、运行进程的实时病毒与木马查杀、以及关键目录的文件备份。阿里云这套 99 元套餐里，针对未购买过云安全中心与文件备份的用户，提供了 0 元开通的三项权益——20 次漏洞修复与 1000 次风险配置检查、2 核主机实时病毒防护、100GiB 文件备份。对小规格机器来说，这三项的意义在于把"人肉巡检"变成周期性自动动作，尤其配置基线检查能揪出自己忘了关的端口。
- 日志与审计：记录登录、提权与关键配置变更，并给日志设轮转上限。
五、备份与恢复：先定义 RTO，再谈备份
备份最容易犯的错是"有备份、没演练"。建议把目标写成可验证的句子：误删一个文件、数据库被误改、整机重装，这三种情况各自的恢复时间目标是多少。
- 文件层：定时快照 + 关键目录增量备份，保留 7–30 天窗口，能选"出事前的时间点"还原。
- 数据库层：每日
mysqldump全量 + binlog 增量，转储文件加密后传到对象存储，不要只留在同一块盘上。 - 演练：每季度真做一次恢复——从备份里拉起一个临时实例，验证数据可读、站点可访问。没演练过的备份只能算心理安慰。
当业务开始有真实用户，扩容顺序也有优先级：先把数据库搬到云数据库（RDS MySQL/PostgreSQL）让应用与数据解耦，再把静态资源搬去对象存储，最后才考虑升配 CPU 与内存。这个顺序的收益比直接升配更明显，因为瓶颈通常先出在"数据和应用抢同一份内存"上。
六、适用边界
2 核 2G 这条线不适合所有场景：高并发接口、大内存应用（Elasticsearch、大型 JVM 服务）、需要 GPU 的推理任务，以及要求多可用区容灾的核心数据库，都不该压在这台机器上。它擅长的是低并发的站点托管、后台服务、开发测试与个人项目的第一个真实地址。
活动页与购买入口在此：https://www.aliyun.com/daily-act/ecs/99program?source=5176.29345612&userCode=aptjpq1x。价格与权益以页面规则为准。
