我第一台云服务器是两年前买的，首年 99 块，第二年续费 480。 当时我盯着那个价格看了很久，最后还是续了——不是因为觉得值， 而是因为所有东西都在上面：网站文件、数据库、图片、 配置、还有那堆我已经忘了当初为什么这么写的东西。

那次之后我想明白了一件事：问题不在于服务器贵，而在于我把自己绑在了上面。

把「机器」和「数据」分开想

大部分人买服务器的顺序是：买机器 → 装环境 → 放数据。 数据是最后才考虑的，于是它自然就长在了机器上。

但换个顺序会舒服很多：

  • 数据是资产，要独立存放、定期备份、随时可取
  • 机器是消耗品，用完就扔，扔了不心疼
  • 配置要代码化，能一条命令重建

这个顺序一旦反过来，很多决策会变得非常轻松。比如： 「这家续费太贵了」——那就换一家，反正数据不在机器上。

具体怎么分层

我把东西按「换机器时要不要跟着走」分成三层：

层级放什么放哪里换机器时
数据层 数据库、用户上传的图片、文章源文件 对象存储 / 云数据库 不用动
运行层 运行时、依赖、临时文件 服务器本地 重建
配置层 Nginx 配置、环境变量、部署脚本 Git 仓库 git clone 拉回来

三层里只有中间那层是「可以随便死」的。

一个具体的例子

我现在的博客是纯静态的，数据层就是一堆 Markdown 文件， 存在对象存储里，本地也留一份。服务器上只跑一个 Nginx， 配置就下面这几行： 

server {
    listen 80;
    server_name example.com;

    root /www/blog;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

哪天这台机器到期了、涨价了、或者机房炸了，我的操作是：

  1. 随便买一台新机器，五分钟
  2. 装 Nginx，把配置粘进去
  3. 从对象存储把文件同步下来
  4. 改 DNS 解析

全程不到半小时，其中二十分钟在等 DNS 生效。

判断一个架构好不好，有个很朴素的标准：
换掉其中任何一个部件，你需要花多久？

代价是什么

说实话，这套做法不是没有成本：

  • 多了一层复杂度。本地开发要模拟对象存储，调试麻烦一点
  • 多花一点钱。对象存储和云数据库通常比塞在服务器上贵
  • 需要一开始就想清楚。事后改造比一开始做对难得多

但如果你的项目打算活过一年，我仍然觉得划算。 因为云服务器这个市场，首年便宜、续费翻倍几乎是默认规则， 你早晚要面对「换还是不换」这个问题。

最后

我不是说所有东西都该上云。小项目、临时项目、玩具项目， 直接塞在服务器上完全没问题，别过度设计。

我想说的只是：在动手之前，先问一句「这些东西以后要怎么搬走」。 问过这一句，很多选择会不一样。