本文记录了我们把自家 Web 服务从 AWS 的常开服务器（EC2）迁到 Google Cloud 的 Cloud Run（东京）和 TiDB Cloud Starter 的过程，涵盖评估、备份、并行运行、DNS 切换、费用与运维的变化、权衡取舍，以及判断是否适合自家公司的自查清单。
2026 年 10 月上旬，SolanaLink Co., Ltd. 把包括公司官网在内的几个 Web 服务，从 AWS 上 24 小时常开的服务器（EC2）迁移到了 Google Cloud 的 Cloud Run（东京区域）。数据库也同时换成了无服务器型的 TiDB Cloud Starter。
本文会尽量具体地介绍：我们如何评估这次迁移、如何控制风险，以及费用大致降了多少。希望能为您判断这种做法是否适合自己的公司提供一些参考。
1. 背景：中小企业让 EC2 全天候运行的成本结构问题
EC2 是 AWS 提供的虚拟服务器。可以把它理解为在云上租了一台自己专用的电脑：只要开着机，不管有没有人访问，都在计费。
中小企业的 Web 服务，经常会遇到下面这些情况：
- 访问集中在营业时间，夜间和节假日几乎没有，服务器却 24 小时开着。
- 除了服务器本身，负载均衡器（负责分配访问流量的设备）、存储、网络和日志的费用，每个月基本都是固定支出。
- 操作系统更新、安全补丁、磁盘容量管理、数据库运维这些维护工作，往往都压在“一人 IT 部门”或开发人员身上。
- 一台服务器上同时跑着多个服务，很难看清每个服务各花了多少钱。
我们也是这种结构。先说结论：自营服务部分的费用，按月换算预计下降约 70%。在拿到 Google Cloud 的实际账单数据之前，迁移后的数字有一部分仍是估算。尤其要说明的是，由于一台服务器上同时跑着多个服务，只迁走其中一部分，AWS 的账单几乎不会减少；只有把服务器和负载均衡器都停掉，费用才会大幅下降。我们在事前评估时也确认了这一点，并把“最终停掉服务器”定为目标。
2. 盘点与技术评估：检查是否适合 Cloud Run
Cloud Run 是一种只在有请求时才运行容器（把应用和运行环境打包在一起的“箱子”）的服务。没有访问时会缩减到 0 台，只按实际用量计费（用多少付多少，也就是所谓的按量计费）。不过，并不是所有应用都能直接搬上去运行，所以我们先从以下几个方面逐项做了确认。
| 检查项 | 确认内容 | 我们的结果 |
|---|---|---|
| 无状态（不在服务器上保存状态） | 重启或增减台数时，数据会不会丢失；有没有把文件存在服务器内 | 图片等文件放在外部存储，没有问题。原先放在服务器内存里的临时数据，重新做了设计 |
| 监听端口 | 是否在 Cloud Run 指定的端口号上监听 | 已经支持，可以直接运行 |
| 后台处理 | 有没有在返回响应之后还继续运行的处理 | 需要修改。审计日志等多处处理是在响应之后异步写入的。Cloud Run 在返回响应后会限制 CPU，写入可能丢失，因此改成在返回响应前等待处理完成 |
| 常驻程序、定时执行 | 服务器内有没有一直运行的调度器 | 定时任务移到外部机制，改由 Cloud Scheduler 执行 |
| 请求超时 / WebSocket | 有没有长时间保持连接的通信 | 客服聊天用了服务器发送事件（持续保持连接的通信）。连接期间会一直计费，所以设计成单次连接最长 5 分钟就断开，再自动重连。以实时通信为主的服务，按时长计费的部分很容易膨胀，需要特别注意 |
| 冷启动 | 在没有访问的状态下，第一个请求会不会变慢 | 会变慢。结果和对策见“7. 结果” |
还有一点很容易被忽视。盘点过程中我们发现，旧架构里本该定时执行的处理，由于配置有误，实际上一直没有运行。迁移也是一个好机会，可以把这类“以为一直在运行”的处理找出来。
没有迁移的部分及原因
我们并没有把所有东西都搬到 Google Cloud。以下几项留在了 AWS：
- DNS（Route 53）：负责域名解析。迁过去好处不大，可一旦出错，公司网站和邮件会同时中断，所以决定不动它。
- 邮件发送（SES）：基于发送记录积累起来的可信度（作为发件方的信誉）已经建立，认证设置也已完成，没有迁移的理由。
- 图片等静态文件的存储与分发：已经稳定运行，迁移也不会降低费用，所以保持原样。
- CDN（加速内容分发的机制）：这次迁移把它放在 Cloud Run 前面。这样可以提前签发 HTTPS 证书，避免切换时出现中断。
另外，数据库方面，我们最初打算选用 Cloud SQL（Google Cloud 的托管 MySQL）。但它每月都有固定费用，所以我们以费用为优先，验证并采用了 TiDB Cloud Starter。部分功能（包含日语的全文检索）与 MySQL 的实现方式不同，因此需要改写检索处理。验证时，我们把同一份数据分别导入 MySQL 和 TiDB 进行比较：用我们核对的文章标题和关键词检索，能否在结果中正确找到，两边表现相同。不过排序并不一致，所以计划在切换后用真实的查询内容再做确认。
3. 迁移后的架构
Before（迁移前）
迁移前的架构：一台 24 小时运行的 EC2 服务器，上面同时跑着多个服务
After（迁移后）
迁移后的架构：应用在 Cloud Run，数据库在 TiDB Cloud Starter，DNS 和邮件留在 AWS
为什么按角色“各司其职”
这次的架构，并不是在 Google Cloud 和 AWS 之间二选一的结果，而是按角色把每样东西放到最合适的地方。
- 应用运行交给 Cloud Run：按用量计费，适合访问量少的服务。
- DNS 留在 Route 53：运行稳定，有多年的运维实绩。切换步骤（调整 TTL、回滚）也只需改写记录即可。
- 邮件留在 SES：发送设置和信誉可以原样沿用。
这并不是“AWS 太贵所以搬走”的故事。问题在于“24 小时不停机、一直租着 EC2”这种用法，跟我们的访问量不匹配。AWS 的长处在于，可以像这次一样，继续使用自己需要的部分。比起把云统一到一家，按角色分开在费用和安全性两方面都更有利。
4. 数据备份
备份了什么、怎么备份
- 迁移前：在切换前夕，导出了生产数据库的转储（把全部数据导出的文件）。数据量很小，压缩后只有几 MB。
- 迁移时的确认：把转储导入 TiDB，确认所有表的行数与原库一致。切换前夕又重新导出最新数据并导入，做了同样的确认。主要表的内容核对（校验和）也一致。当时只有 1 条在新旧之间写入的浏览记录显示为差异，属于预料之内的差别。
- 迁移后：使用 TiDB Cloud Starter 的自动备份（每天 1 次）。我们在管理界面确认过，保留期为 14 天。
- 旧环境的数据：在旧环境停止之前，一直保留着数据库里的数据。此外，切换前导出的转储文件也在本地另存了一份。
有没有做恢复验证
- 把切换前的转储导入另一个数据库（验证用）并确认内容，也就是“从转储恢复”，已经做过。上面提到的行数核对和检索结果比较，就是这次验证的记录。
- 另一方面，从 TiDB 自动备份实际恢复的演练，目前还没有做。
我们也清楚以下这些限制：
- Starter 没有按时间点恢复（回到某个特定时刻的功能），恢复时会新建一个集群。
- 我们也考虑过每晚导出到另一个存储位置，但为了控制费用而作罢。自动备份是唯一的备份。
- 旧环境停掉之后，就没有退回旧环境的办法了。迁移完成后，备份反而更加重要。
从我们自己的案例中得到的一个教训是：“备份只有真正恢复过，才算可用。”迁移后的恢复演练，是我们今后的课题。
5. 并行运行
在切换前后，我们让旧环境（EC2）和新环境（Cloud Run）同时运行，时间是 2026 年 10 月 3 日至 4 日。旧环境的服务器在 10 月 4 日晚上停止。从 AWS 的每日账单数据也确认了：5 日以后不再产生服务器和负载均衡器的费用。
这段时间里我们做了以下几件事：
- 切换前的预先验证：在不改动公共 DNS 的前提下，直接访问新环境确认运行情况（只在自己手边的终端上，把域名解析指向新环境来确认）。
- 数据的最终同步：切换前夕，把旧数据库的最新内容导入新环境。导入几十秒就完成了，并确认所有表的行数一致。
- 切换后的确认：反复多次检查公开 URL 的所有页面是否正常响应、登录后的回调地址是否正确、HTTP 到 HTTPS 的跳转，以及有没有服务器错误等。刚切到新环境时，也确认了旧数据库没有新的写入。
- 为写入空窗做准备：从数据同步到 DNS 切换对所有人生效，大约有 1〜2 分钟，这期间仍可能有数据写进旧环境。我们事先确认过这类写入很少，并定好了步骤：切换后检查旧数据库，如果有新数据就手动重新录入。
- 以用户身份确认：由负责人在生产环境中实际操作确认。
- 登录：切换当天早上，确认用 Google 账号登录和两步验证都能正常使用。
- 咨询表单：确认过程中发现了一个迁移前就存在的问题，并在当天修复。切换后的确认不只是在验证迁移本身，也是发现原有问题的机会。
旧环境在切换后待命了大约 1 天，保持随时可以切回的状态。另外，实际上并没有哪段时间是两个环境同时接收用户访问的，我们的做法是“先在新环境验证，再切换，旧环境待命”。
6. DNS 切换
DNS 是“把域名和服务器地址对应起来的机制”。切换时的关键，是如何缩短地址变更传遍全球所需的时间。
- 提前调低 TTL：TTL 是其他服务器缓存 DNS 应答的时长。我们在切换前 1 小时以上，把 www 记录的 TTL 从 3,600 秒降到 60 秒。根域名（不带 www）用的是 Route 53 的别名记录，TTL 本来就固定为 60 秒。我们先算好旧应答的缓存全部过期的时间点再切换，所以切换后几分钟内就生效了。
- 先签发证书：HTTPS 证书在切换之前就已签发完毕，因此不存在 HTTPS 无法使用的时间段。我们在另一个服务上试过“Cloud Run 域名映射”这种方式，证书签发和传播导致了约 25 分钟的中断，所以正式网站没有采用这种方式。
- 确认 CAA 记录：CAA 是一种 DNS 记录，用来指定允许哪些证书颁发机构签发证书。我们的域名没有设置 CAA 记录，所以证书签发不会被 CAA 拦下。如果您设置了 CAA，需要事先把新环境使用的证书颁发机构加入允许列表。
- 不碰邮件相关记录：MX、SPF、DKIM、DMARC 等邮件相关记录，以及各种用于验证域名所有权的记录，一概不改。要改的只有用于显示网站的 2 条记录。这样就避免了对邮件收发的影响。
- 回滚步骤：如果出现问题，就把这 2 条记录改回原来的指向。TTL 是 60 秒，大约 1 分钟就能生效。如果只是 Cloud Run 一侧的问题，用 1 条命令把流量切回上一个版本（修订版本）即可。不过，切换后写入新数据库的数据并不在旧数据库里，所以如果在真实用户已经开始使用之后再回退，需要先把这些数据导出来。
- 切换之后：稳定运行 1 天左右后，把 TTL 改回原值，并停止旧环境。原本共用的负载均衡器等，当时并不删除，而是计划只移除相关服务的部分。目前 www 的 TTL 已经恢复为原值（3,600 秒）。
7. 结果
费用
自营服务部分 削减约 70%（按月换算的预估）。在用 Google Cloud 的实际账单数据最终确认之前，迁移后的数字有一部分仍包含估算。
比较条件如下：
- 迁移前：迁移前最后一个完整月份（2026 年 9 月）的 AWS 账单中，计算资源、负载均衡器、存储、网络流量和日志这几类费用里属于自营服务的部分。
- 迁移后：按 2026 年 10 月的实际节奏折算出的整月金额中，自营服务的部分。其中包含 Google Cloud 的费用和托管数据库的费用。原本没有在 AWS 上运行的自营服务，其费用也计算在内，所以这是一个刻意从严的比较。
- Route 53 和 SES 仍留在 AWS，因此迁移前后都不计入。
- 全文统一使用同一种货币和同一个汇率。
- 自营服务部分的计算方法：迁移前，1 台服务器和负载均衡器由多个服务共用，账单无法按服务拆分。因此，迁移前的费用按服务个数平均分摊。由于不清楚每个服务实际用了多少，这种分摊只是一种假设，削减率会随分摊方式而上下浮动。
迁移后还没有满一个月的完整账单，所以写作“按月换算的预估”。等完整一个月的数据出来后，我们会更新本文。
Cloud Run 有免费额度，这拉低了迁移后的费用。假设没有免费额度，削减率会再低几个百分点，预计略低于 70%。
月度费用指数（自营服务部分）：迁移前 100，迁移后 30（按月换算的预估）
| 指数 | |
|---|---|
| 迁移前（2026 年 9 月） | 100 |
| 迁移后（按 2026 年 10 月的节奏换算成整月） | 30 |
运维方面的变化
- 不再需要给操作系统打补丁：服务器操作系统和中间件的更新由 Google 负责。
- 部署（上线）变轻松了：以前是在生产服务器上直接构建，构建期间响应会慢上几秒，每次上线还会中断 9 秒左右。迁移后是先启动新版本再切换，不会中断。
- 回滚只需 1 条命令。
- 定时任务能按设定的时间准时运行了。
- 不用再管理服务器台数，也不需要监控磁盘容量或扩容。
- 机密信息可以放在专用的保管库（Secret Manager）里管理了。
权衡取舍
- 冷启动：一段时间没有访问，台数就会降到 0，之后的第一次访问会变慢。据我们测量，空闲后首次打开约 5 秒，之后在 0.2 秒前后。有些服务预计会超过 10 秒。大部分时间花在第一次连接数据库（加密握手）上。对策是设置“始终保留 1 台待命”，但会额外产生固定费用。也可以只在审核日或商务洽谈演示当天临时启用。
- 按量计费不好预测：无服务器数据库按读写量计费。我们遇到的情况是，存活监控的访问让数据库查询量增加得超出预期，占了用量的大半。设定月度上限很重要，但一旦达到上限，该数据库就不再接受新连接，所以上限值和监控方式必须放在一起设计。
- 单实例的限制：我们没有使用缓存服务器，而是在进程内实现替代，并选择了最多只运行 1 台的架构。流量小的服务没有问题，但不适合靠增加台数来应对。
- 迁移工作本身：需要修改代码（响应后的处理、日志格式、数据库连接设置、检索处理的改写）。
- 无法再退回旧环境：旧环境停掉之后，只能依靠备份。
8. 自查清单：这种迁移适合您的公司吗
适合的企业
- 访问量少，或者随时段、星期几的波动很大。
- 目前服务器（EC2 等）的费用大部分是固定费用。
- 能把同一台服务器上的服务一起迁走，从而停掉旧服务器。
- 应用可以容器化，或者已经在容器中运行。
- 能做到不把密码、API 密钥等机密信息打包进容器镜像，而是在运行时从专用保管库传入。
- 公司里维护人员少，希望减少操作系统更新和服务器监控的工作量。
- 可以接受几秒的冷启动，或者愿意负担始终保留 1 台待命的费用。
- 能把切换后的数据备份、乃至恢复演练纳入日常运维。
不适合（或应慎重考虑）的企业
- 以持续连接的通信（WebSocket 等）为主，费用会随连接时长不断膨胀。
- 全天 24 小时都有稳定的大量访问。这种情况下，常开的服务器有时反而更划算。
- 应用把状态保存在服务器内的文件或内存里，难以改造。
- 依赖响应后继续运行的处理或常驻程序。
- 数据库对特定的 MySQL 功能依赖很深（改用 TiDB 时必须核实兼容性）。
- 切换后无法保留退回旧环境的手段，而且备份的运维也还不完善。
- 所用的 AWS 服务之间耦合很紧，没法只拆出其中一个。
只要有一项让您不放心，建议在迁移之前先通过费用诊断理清整体情况。
9. 下期预告
下一篇将介绍我们如何评估“是否应该把多个 TiDB 实例整合到 1 个 Cloud SQL”，以及实际操作的情况。减少实例数量，可能会减少管理工作；但另一方面，计费方式会改变，故障时的影响范围也可能扩大。整合并不一定是正确答案。我们会中立地整理利弊，并如实写出结果。另外需要说明，我们并不承诺费用一定会因此下降。
10. 咨询
SolanaLink Co., Ltd. 正在筹备面向中小企业的“云费用诊断”服务。我们会帮您梳理目前的架构和账单明细，一起确认是否适合迁移、迁移到什么程度、风险在哪里。
如需咨询，欢迎通过官网的咨询页面联系我们。
SolanaLink Co., Ltd.（作者：Tony Cai）
免责声明：本文中的数字来自我们自己的案例，实际效果因环境而异。费用削减率是自营服务部分的数字，是按 2026 年 10 月时的实际节奏折算成整月的预估。迁移前的费用按服务个数分摊。待完整一个月的账单确定后，我们会更新本文。
评论
评论 (0)