企业官网建设流程全解析

1. 一个经典的"省钱"陷阱：为什么先在 ECS 上自建数据库这么诱人

1.1 创业初期最容易走的路：租台 ECS 自己装 MySQL

我见过太多团队，尤其是百人以下的技术团队，最早都是从一台 ECS 起步的。业务还没上线，老板说先省着点花，运维同学还没到位，DBA 更是奢望，于是架构就变成了：一台 ECS 上部署应用，同一台机器或者再开一台 ECS 装上 MySQL，内网 IP 一连，业务就转起来了。

这个路径之所以诱人，不是没有道理。一台 2C4G 的 ECS 按量付费一个月也就几十块，包年甚至更便宜。RDS 的入门规格虽然也不贵，但和自建比起来，总有一种"同样的配置，为什么托管要贵一截"的心理落差。再加上很多开发者对数据库的印象还停留在"apt install mysql-server"就能跑的阶段，觉得 MySQL 不过如此，为什么要多花钱去买云服务？

这个想法在业务只有几百个用户、一天几千请求的时候，确实带不来什么致命问题。但我要先泼一盆冷水：你装起来的是 MySQL，但你真正需要的是一套完整的数据服务。"装起来"和"服务可用"之间隔着的，是高可用、备份恢复、监控告警、性能调优、安全加固这一整套能力。ECS 只是给你了一台虚拟机，而数据库系统的高可用和可靠性，需要你自己用工程手段去补。

1.2 自建数据库的典型架构长什么样

为了后面说清楚差异，我先还原一下大多数 ECS 自建 MySQL 的真实部署形态。正常一点的自建架构是这个样子的：

• 一台 ECS 跑应用（比如 Java 应用、PHP-FPM、Node.js 服务）；
• 一台 ECS 作为数据库主库，数据盘用云盘或本地 SSD，MySQL 数据目录放在数据盘上；
• 如果稍微有点工程意识，会再开一台 ECS 作为从库，靠主从复制做数据冗余；
• 部署一套 crontab 定时任务，半夜凌晨用 mysqldump 做逻辑备份，或者用 XtraBackup 做物理备份，传到 OSS 上；
• 所谓的"高可用"是：写一个巡检脚本，检测到主库挂了就尝试拉起进程；或者是配了 MHA / Orchestrator，但从来没演练过切换过程。

这套架构在初期是可以工作的，但它的脆弱点非常明显。首先，ECS 本质上还是一台宿主机上的虚拟机，虽然云厂商提供了多副本机制来保障云盘数据可靠性，但虚拟机所在的物理机一旦发生故障，宿主机热迁移、云盘重新挂载、操作系统内核异常，这一串连锁反应并不是你能控制的。云厂商给的 ECS 可用性承诺，只代表这台虚拟机能用，不代表你装在里面的 MySQL 服务永远健康。

更麻烦的是主从复制。自建主从复制方案里，半同步复制、异步复制的选择直接影响数据一致性。用异步复制，主库 binlog 还没传到从库就宕机，内存里已经提交的事务就要丢；用半同步复制，虽然多了一层保障，但每个事务都要等待从库 ACK，延迟高了会影响写入性能。这个平衡对没有专职 DBA 的团队来说，几乎不可能调到最优。我见过一个团队用异步复制搭主从，大促期间主库磁盘直接打满，binlog 没有同步到从库，从库追了三个小时延迟，最后主库重启时崩了，数据丢了将近十分钟的量，业务整整停了半天。

这就是 ECS 自建数据库的真实写照：不是"不能跑"，而是它的运行质量完全取决于团队花了多少精力去维护。早期流量小的时候，问题还会迟到，但一定不会缺席。

1.3 从"还能跑"到"随时翻车"的临界点

很多团队对一个问题的感知是滞后半拍的：业务已经跑起来了，QPS 涨上去了，数据库却还是那台只有 2C4G 的 ECS。

第一个会出问题的往往是磁盘。MySQL 的 binlog、undo log、临时文件、慢查询日志都会不断膨胀，云盘空间一旦用满，MySQL 会直接进入只读保护状态。你想想，半夜两点用户正在下单，突然所有写入全部报错，应用日志里全是"SQLSTATE[HY000]: General error: 1021 Disk full"，这种事故对核心业务来说就是致命的。

第二个出问题的是连接数。应用侧的连接池没配好，或者某个服务出现线程阻塞，瞬间可以把 MySQL 的 max_connections 打满。自建环境下你没有一整套会话级别的监控，等你想查的时候，SSH 上去执行SHOW PROCESSLIST可能都卡住。

第三个出问题的是主从延迟和锁等待。业务一旦开始做报表查询、后台导出、定时任务，这些大查询经常会和线上交易请求抢资源。如果恰好某个大查询跑到主库上，行锁把关键的订单表堵住，后面的写入全部排队，用户体验就是"页面转圈、按钮点了没反应"。

我遇到过最典型的一个场景是：一个电商系统早期为了省钱，把订单库、商品库、用户库全部塞在同一台 ECS 的 MySQL 实例里。高峰时期，一次后台导出三个月订单的报表，直接拖垮了整个库，所有业务接口的响应时间从 30ms 涨到 3 秒以上。这就是"省钱一时爽，爽完火葬场"的现实版本。

所以，ECS 自建数据库的核心问题不在于"单机"这个形态，而在于你选择了单机，就等于默认放弃了变化。业务可以线性增长，数据库不会自己跟着增长。等你发现需要扩容的时候，往往已经是事故现场了。

2. 企业级数据库架构的分水岭：RDS 托管到底改变了什么

2.1 RDS 不是"云上的 MySQL"，它是一套完整的数据库服务

很多人的误区是把 RDS 理解成"MySQL 装在了云服务器上，厂商替你看管"。实际上，RDS 的架构和 ECS 自建有本质区别。

RDS 的第一个变化是控制面与数据面的分离。你在控制台创建实例、改参数、重启、扩容，这些都是控制面 API 在起作用；底层数据面是一个真实的高可用集群。以阿里云 RDS MySQL 为例，创建实例时默认会部署主备两个节点，主节点承担读写，备节点实时同步。主备之间通过底层的物理复制或者 binlog 同步保持数据一致，一旦主节点发生故障，系统会自动探测并切换到备节点，整个过程对业务层透明。

第二个变化是数据安全性不再依赖单块云盘。RDS 底层的数据存储采用了分布式存储引擎，数据会以多副本的方式冗余在存储层。这意味着即使某个物理存储节点出现故障，数据也不会丢，存储层会自动完成副本重建。这个能力在 ECS 自建环境下几乎不可能实现，因为你看到的只是一块标准的云盘，云的可靠性承诺和使用 MySQL 自己的复制机制是两回事。

第三个变化是备份恢复能力的工程化。自建数据库最常见的问题就是"备份有没有生效不知道，真正要恢复的时候恢复不出来"。RDS 提供的是自动化备份策略，支持全量备份、binlog 日志备份和按时间点恢复。在自己 ECS 上做 PITR（Point-in-Time Recovery），需要维护一套 binlog 归档脚本，任意一天的 binlog 不完整，整个时间点恢复就是空的。而在 RDS 上，你只需要在控制台上选一个时间点，系统会自动拼接全量备份和后续 binlog，把实例恢复到那个时刻。

2.2 你省下来的不是钱，是大量隐性运维时间

RDS 的价值，很多时候要用"时间账"来算才说得清楚。

先说内核优化。阿里云 RDS 的 MySQL 是基于官方版本深度定制的 AliSQL，针对高并发、热点更新、秒杀类场景做了大量优化。比如在双十一这种场景下，热点商品库存只有一条记录，大量并发更新会导致行锁竞争严重，AliSQL 对热点行更新做了专门优化，在相同硬件条件下能支撑的 TPS 比社区版 MySQL 高一截。这种能力，你自己下载一个 MySQL 源码包编译是拿不到的。

再说安全能力。RDS 开箱自带白名单、SSL 加密、SQL 审计、透明数据加密（TDE）这些功能。放在自建环境里，光是一个数据库审计就有得忙：要么自己解析 binlog 做巡检，要么上第三方审计插件，还要担心性能损耗。而合规审计需求一来，RDS 控制台点几下就能把审计日志导出。

然后是监控告警。RDS 自带一整套监控体系，CPU 使用率、内存、磁盘 IOPS、连接数、慢查询数、死锁数，全部可以在控制台看趋势图，也可以配置告警规则。自建 MySQL 不是没有这些指标，而是你缺一个采集、存储、展示的链路。最常见的自建监控方案是搭一套 Prometheus + mysqld_exporter + Grafana，这套链路本身就要花一两个星期去部署调优，而且数据库一挂，监控系统往往是最后知道的。

用 RDS 之后，这些通用能力都由平台承担了，你只需要关注业务层的数据库设计、SQL 质量和容量规划。这些时间省下来，投入到业务代码上，投入产出比是完全不同的。

2.3 但 RDS 也不是银弹

我不能把 RDS 说得天花乱坠，因为在真实使用中，它也有一堆前提条件。

首先是规格上限问题。RDS 虽然托管了运维复杂度，但它本质还是一个单实例（主备模式）的资源模型。你选了 8C16G，峰值就只能用 8C16G。大促前如果不提前升级规格或者做好弹性策略，一样会被打爆。虽然 RDS 有自动弹性功能，但触发条件和资源预算都需要提前配置，不是凭空出现的能力。

其次是闪断问题。RDS 的主备切换，无论做得多快，都会造成秒级闪断。对于没有配置连接池重连机制的应用来说，一次切换就可能引发一波连接异常报错。所以上 RDS 不代表应用层可以完全无感知，你仍然要确保连接池重试、断线重连这些基本能力是健全的。

第三个问题是：RDS 不负责你的 SQL 质量。索引没建好，慢查询照样慢；事务拆解不合理，锁等待照样严重；大查询依然会拖垮小规格实例。托管的是实例生命周期，不是数据库设计。很多团队从 ECS 自建迁到 RDS 后，发现性能问题一个没少，只是排查手段更顺手了而已。

所以我的结论是：RDS 是从"自建单机"走向"企业级数据服务"的第一步，它解决了 80% 的基础运维问题。但如果你的业务已经进入核心交易、大促弹性、海量连接这个量级，单实例架构本身反而会成为下一个瓶颈。

3. 从"托管"到"原生分布式"：瑶池数据库的架构进化

3.1 瑶池数据库到底是什么

聊瑶池数据库之前，要先理清一个概念。瑶池是阿里云数据库品牌的总称，旗下包含了很多产品线：主打云原生关系型数据库的 PolarDB、云原生数据仓库 AnalyticDB、多模数据库 Lindorm、以及兼容 MySQL 和 PostgreSQL 的 RDS 系列等。所以你看到的"瑶池数据库"不是一个单一产品，而是一整支面向不同场景的数据库家族。

在这篇文章讨论的核心业务背景下，与 ECS 自建 MySQL 最直接的对比对象，是瑶池数据库家族中的 PolarDB MySQL 引擎。一句话概括它的定位：PolarDB 是在架构层面彻底重构的云原生关系型数据库，不再是传统的单机 MySQL 套壳。

RDS 和 PolarDB 表面上看都是"MySQL 兼容数据库"，但二者的底层设计哲学完全不同。RDS 的模型还是经典的"一台主库 + 一台备库 + 若干只读实例"，数据通过复制协议在节点间拷贝；而 PolarDB 从第一天起就是为云环境设计的，采用存储计算分离架构，把传统数据库里最重的存储部分下沉到分布式存储层。

3.2 存储计算分离如何改变高可用和扩展性

传统主备复制模型有一个天然问题：备库的数据是"追"出来的。主库写了事务，生成 binlog（或 redo log），通过网络传给备库，备库拿到日志后回放到本地存储。这个过程中，任何网络抖动、IO 延迟、大事务回放，都会导致主备延迟。延迟一旦出现，备库就既不能承担读流量（因为数据旧），也不能在故障时快速接管（因为还有大量日志没回放完）。

PolarDB 的存储计算分离架构直接把这个逻辑倒过来了。整个集群只有一个共享存储池，主节点和只读节点之间不需要通过 binlog 同步完整数据，所有节点访问的是同一份数据文件。底层的分布式存储负责多副本的一致性，计算节点只需要维护自己的缓存和 redo log，从存储层读取需要的数据块即可。

这意味着什么？第一，主备切换不再需要"追日志"。主节点故障后，新的主节点挂载同一份存储数据，秒级完成接管，不存在旧数据被"追"的过程；第二，读写扩展能力大幅提升。因为只读节点不需要复制完整数据文件，新挂一个只读节点非常轻量，PolarDB 可以在一套存储上支撑最多 15 个只读节点，这些节点共享同一份数据，不需要每台都存一份全量副本，成本比 RDS 的只读实例低得多。

还有一个非常实用的能力是 Serverless 弹性。传统 RDS 的规格是固定的，大促时手动升级规格、结束后再降级，整个过程要挪数据，窗口长、风险大。PolarDB Serverless 版本可以根据实际负载自动弹性伸缩，算力规格在设定的上下限之间动态变化，业务低谷时甚至可以缩容到接近 0，按实际使用的计算和存储量计费。对于有明显波峰波谷的业务，这个模型比"包年包月固定规格"要省钱得多，也比高峰时业务被打爆要安全得多。

3.3 为什么"核心业务必须用瑶池数据库"

如果只是架构先进，那还不足以说服我给出"必须"这个结论。我见过太多人觉得"核心业务就是 MySQL，换什么架构都一样"。但在真实的生产环境中，核心业务数据库的基本诉求有三条：数据不能丢、服务不能断、流量上来时扛得住。这三条，单机自建几乎做不到，RDS 能做到一部分，而瑶池体系下面的 PolarDB 才是真正在这三条上都拉满的选项。

先讲数据不能丢。传统 MySQL 主从架构下，即使配了半同步复制，极端情况下依然存在主库宕机、事务未同步到备库、数据丢失的可能。PolarDB 底层采用分布式存储的多副本同步机制，数据写入存储层的多副本成功后才返回事务提交成功，从物理层面保证了不丢数据，RPO 接近 0。这不是加了几个配置项能做到的，而是架构层面换了底座。

再讲服务不能断。核心业务最怕的就是故障切换时间太久。自建主从切换，要经历检测、排查、提升备库、修改指向、检查延迟这一整套动作，顺利的话十几分钟，不顺利的话几小时。PolarDB 的计算节点挂载同一份存储，切换时数据已经在共享存储上，业务侧重新连接到新主节点即可，RTO 可以做到秒级甚至更快。这个差异在凌晨两点数据库故障、老板电话连环响的时候，感受极其明显。

最后讲扛得住流量。核心业务通常意味着高并发、大流量。PolarDB 的一写多读架构让你可以在大促前快速增加只读节点，配合应用侧读写分离，读扩展能力可以做到线性增长。而它的性能指标在相同规格下也普遍优于自建 MySQL：在阿里云官方的公开测试数据中，PolarDB 的性能可以达到社区版 MySQL 的数倍甚至更高，原因就在于内核针对云环境做了大量优化，比如并行查询、物化视图、Redo log 优化等。

3.4 什么样的业务才算"核心业务"

我说"核心业务必须用瑶池数据库"，不是让所有人都无脑去迁移。先想清楚，你的业务库里装的是什么数据。

判断标准很简单：**如果这张表的数据丢了、坏了、或者不一致了，公司会产生直接的经济损失或者法律风险，那它就是核心业务数据。**典型的例子：账户余额表、订单表、支付流水表、库存表、用户身份信息表。这些都是金融级别的要求，容不得半点闪失。

反过来，有些数据不满足这个标准，比如内部 Wiki、测试库、临时报表、爬虫抓取的数据、个人项目的数据。这些数据丢了顶多是重新跑一遍，或者花时间恢复，不会造成直接损失。这类场景，ECS 自建一个 MySQL 完全够用，甚至 SQLite 都行。

但现实是，很多团队在业务早期没有做这个区分，所有数据都堆在同一台 ECS 的 MySQL 里。等业务发展起来，想做区分的时候，才发现迁移核心数据本身就是一次巨大的工程。所以我的建议是：从一开始就按下图思路部署——核心交易类数据直接上瑶池 PolarDB，边缘数据用 RDS，非关键数据可以自建。哪怕前期为了节省成本，至少也要给核心数据单独开一台 RDS。

4. 核心业务选型决策表：到底什么时候该上瑶池

4.1 用一张表把选型逻辑理清楚

聊了这么多架构原理，最后落到选型上。我整理了一张决策表，把 ECS 自建 MySQL、RDS MySQL、瑶池 PolarDB MySQL 放在一起对比。列出的维度直接对应平时最容易踩坑的地方：

这张表不是为了说明 PolarDB 在每一行都碾压 RDS，这不客观。实际上，RDS 在中等规模业务下完全够用，而且成本控制更直接。真正要传达的是：不同业务等级，对应不同架构形态。核心业务的上限决定了你应该选择上限更高的数据库，而不是够用就行。

4.2 不同阶段的迁移路径建议

如果你现在还在早期阶段，可以参考我这边的建议路径走，避免后面翻大车：

• 0 到 1 阶段（原型验证、个人项目、日活几百）：用 ECS 自建没问题。但请务必做到三条：数据目录挂在独立云盘上，至少每周做一次全量备份并下载到本地验证可恢复性，绝对不要把备份文件只放在同一台机器上。这个阶段的核心目标是把业务跑通，不是把数据库架构做得多先进。

• 1 到 100 阶段（有真实用户、有交易、有付费）：建议尽快把核心交易数据迁到 RDS 或 PolarDB。不要自己搭主从，不要自己写高可用脚本。DTS 迁移几乎可以做到不停机，一个周末就能完成。用 RDS 保底，然后逐步把最关键的订单、支付相关库迁移到 PolarDB。

• 规模化阶段（百万用户、大促秒杀、数据量超过几百 G）：核心库直接上瑶池 PolarDB，尤其是大促型业务，必须用到它的弹性能力和一写多读架构。这个阶段如果还停留在 ECS 自建，每次大促都是一次赌博，赌的是宿主机不挂、磁盘不慢、主从不延迟。

很多人的困惑是"我现在业务还不够大，上 PolarDB 是不是太早了？"我的建议是，算一笔风险账而不是规模账：一次数据库宕机带来的业务损失，可能已经超过 PolarDB 一整年的费用差额。架构决策不能只算软件费用，要算事故成本。

4.3 成本算账不能只看包年价格

说到费用，我把四种方案在同一近似配置下做个简单估算（以常规按量/包年的大致价格区间为例，具体价格随地域和促销变动较大，这里只看量级）：

从表面上看，PolarDB 的包年价格不一定比 RDS 便宜，甚至早期会略贵一点。但如果你的业务有明显的波峰波谷，PolarDB Serverless 在低峰期自动缩容，实际账单很可能比固定规格的 RDS 还低。更关键的是，你省掉了大促前的规格升级操作和升级过程中的数据迁移风险。把 DBA 的工资、事故的损失、通宵排查的时间折算进去之后，很多"省钱"的架构选择反而是最贵的。

5. 迁移路径与踩坑经验：从自建到瑶池如何平滑过渡

5.1 迁移前必做的体检清单

一旦决定迁移，最忌讳的就是"直接 DTS 一拉，切过去完事"。迁移核心数据库是外科手术级别的操作，术前检查做不好，术后并发症能让你怀疑人生。

我建议迁移前先跑这样一份体检清单：

• 版本和参数确认：源库 MySQL 版本（5.6 / 5.7 / 8.0），目标库 PolarDB 的版本兼容性；重点检查 lower_case_table_names、sql_mode、character_set_server、time_zone 这些影响行为的关键参数。例如你在自建环境用了sql_mode的自定义组合，迁移后没有对齐，同一个 SQL 可能在目标库直接报错。
• 表引擎和字符集梳理：检查是否存在 MyISAM 表，PolarDB 默认 InnoDB，需要提前转换；检查每张表的 CHARACTER SET 和 COLLATION，中文字符集不一致会导致排序和比较行为变化。
• 触发器、存储过程、事件调度器：这些对象 DTS 不一定能完整迁移，需要导出后在目标库手工创建，并且要确认创建语法在 PolarDB 的内核版本下能正常编译。
• 大表体检：找出数据量超过 100 G 或者行数超过一亿的表，评估迁移时间；这些表最好拆分成多个任务并行迁移，避免单个任务跑太久。
• 清理历史数据：迁移前把不需要的归档数据、中间表、临时表删除，迁移的数据越少，切换窗口越短，出错概率越低。

5.2 DTS 全量 + 增量迁移实操要点

数据迁移方式，官方推荐的是 DTS 的数据同步任务。DTS 可以做全量迁移加增量同步，全量阶段把历史数据导过去，增量阶段持续同步源库的 binlog 变更，最终做到两端数据一致后，在业务低峰期切换。

实际操作中，我习惯按以下步骤走：

1. 先在测试环境完整演练一遍，记录全量迁移耗时和增量同步延迟基线；
2. 正式迁移时，先启动全量任务，观察任务状态，不要急着做增量；
3. 全量完成后，启动增量同步，让源库和目标库保持同步状态，延迟维持在 1 秒以内；
4. 核对数据一致性，重点对比核心表的总行数和关键字段的 checksum，比如对订单表做COUNT(*)和MAX(id)，对余额类表抽样比对 SUM 值；
5. 业务低峰期，停止源库写入（可以设置短暂只读），确认增量延迟归零，切换应用连接串指向目标库；
6. 观察 30 分钟到 1 小时，确认业务正常后，再关闭源库的写入入口，此时迁移窗口正式关闭。

很多人会忽略的一个步骤是回滚预案。切换后如果发现重大问题，要能快速把连接串切回源库。所以源库在迁移后至少要保留一周到两周的只读状态，不要马上释放资源。DTS 的增量同步任务也不要立刻删除，万一需要回滚，增量链路还能把目标库的新数据同步回源库。

5.3 切换后应用侧最容易翻车的细节

数据迁移成功只是第一步，真正容易翻车的往往是应用侧的细节。我把自己踩过的和帮别人排查过的几类问题列在这里：

• 连接池没有合理配置：PolarDB 的连接地址分为集群地址、主地址和只读地址。应用里的读写分离要配好：写入走主地址（或集群地址的写节点），只读查询走只读地址。如果所有流量都打在同一个主节点上，只读节点就白白浪费了。连接池的最小空闲连接数、最大连接数、连接超时时间都要根据目标库的规格重新计算。很多应用之前连自建 MySQL 用的是短连接，迁到 PolarDB 后连接数突增，直接把实例连接数打满，这种情况我见过不止一次。

• 时区和日期时间问题：自建 MySQL 的time_zone参数通常是SYSTEM，跟随服务器时区。PolarDB 默认可能是+08:00。如果应用代码里用了NOW()或者CURRENT_TIMESTAMP，同一个时间函数可能返回不同的值，订单的创建时间、统计报表的日期分组就会出现偏移。这种问题排查起来非常隐蔽，通常要对比日志才发现。

• 大事务和长事务的风险：PolarDB 虽然性能强，但存储计算分离架构下，长事务意味着 redo log 在存储层持续积压，大查询的中间结果集也会占用更多资源。有些之前在自建 MySQL 里"勉强能跑"的大事务，在 PolarDB 上反而更容易触发存储层的压力。迁移后要重点梳理那些事务执行时间超过几秒的业务逻辑，能拆就拆，能改小就改小。

• 主备切换后的连接处理：即使 PolarDB 切换很快，已经建立的连接也会断开，应用必须依赖连接池的重连机制自动恢复。如果应用没有配置重连，一次切换就可能造成大量报错。这也是为什么我反复强调，应用侧的高可用意识和数据库本身的高可用能力同样重要。

5.4 迁移后的一些真实体会

最后分享几个我自己的经验判断，不一定适合所有团队，但值得参考。

首先是不要把"迁移"当成一个周末就能完成的孤立任务。我从 ECS 自建 MySQL 迁到 PolarDB 的经验是：正式切换之前，至少要留出两到三周时间做测试环境的演练、应用侧连接改造、参数对齐和压测。数据迁移本身可能只花半天，但前置的调整和后置的观察期往往才是大头。

其次是建议用"影子迁移"的方式降低风险。具体做法是：在正式切换前，让一部分请求（比如 5% 或 10% 的读流量）先打到 PolarDB 的只读地址上，验证查询性能和数据一致性，确认没问题后再全量切换。这个做法在小团队里可能显得"过度工程"，但对核心交易库来说，多一层验证永远值得。

另外要提醒的就是：**迁移完成后，之前自建 MySQL 的备份脚本、主从监控、巡检任务可以下线，但心理上不要立刻松懈。**上线后第一周要盯紧慢查询、锁等待、连接数、CPU 使用率这几项核心指标，把新技术栈的"正常水位"摸清楚。之后再遇到大促或者流量高峰，你才敢确认它能扛得住。

核心业务数据库这件事，我个人的态度向来是不做极端选择。不是说 ECS 自建一无是处，也不是说瑶池数据库能解决一切问题。但如果你问我，预算有限的前提下，最应该花钱的地方是哪一块，我会毫不犹豫地回答：核心业务数据库。应用代码可以重构，业务逻辑可以改，但数据一旦丢了，很多损失是永远都补不回来的。把核心数据放在一个架构设计更合理、容灾能力更强的数据库服务上，是我做过的最值回票价的架构决策。