企业官网建设流程全解析

简介：一份系统梳理阿里云SLB、ECS、OSS、RDS四大核心服务及系统数据迁移方法的技术文档，面向云计算运维、架构设计与开发人员，适合需要掌握阿里云常用组件并规划数据迁移方案的读者。文档以单个docx文件交付，压缩包大小约1.78MB，目录结构清晰，依次覆盖对象存储OSS的相关概念、存储类型与管理手段，关系型数据库RDS的实例、备份恢复与数据库迁移服务，以及负载均衡SLB的监听器、后端服务器、健康检查等关键机制，同时结合ECS云服务器讨论系统迁移中的基础资源配合，并配有各服务的使用方式、管理工具与常见功能说明。内容不仅介绍各服务的基础用法，还通过典型应用场景说明如何在数据迁移中组合使用OSS承担非结构化存储、RDS管理结构化数据、SLB分发业务流量，从而提升整体架构的可用性与扩展性。从概念到功能再到运维要点逐层展开，适合当作云上架构入门与迁移实践的参考资料。该资源目前已有778人学习浏览，具有较好的参考热度。

1. 到底什么是阿里云SLB-ECS-OSS-RDS：四个缩写，一场开店生意经

你有没有过这种瞬间：业务要上云，同事丢过来一张架构图，图上写着“SLB-ECS-OSS-RDS”，四个缩写排成一排，你盯着看了半天，每个字母都似曾相识，但连起来就不知道它们各自负责什么、为什么非要凑在一起。别慌，用开餐厅来类比，一分钟就能建立认知。

一家餐厅要正常运转，至少要有四样东西：一个地方放食材和半成品，一个厨房负责炒菜，一本账本记录每一笔收支，再有一个门口迎宾的人负责把客人安排到不同的桌子。阿里云SLB-ECS-OSS-RDS对应的正是这四件事：OSS是仓库，ECS是后厨，RDS是账本，SLB是迎宾。通俗地说，这是一套把“存储、计算、数据库、流量分发”拆开、各自独立又互相配合的云端架构组合。搞懂这套组合，你就搞懂了大多数中型网站和App是怎么跑起来的，也就能看懂后续系统迁移到底在迁什么。

2. ECS和OSS：一台能登录的云电脑，和一个“没有文件夹”的仓库

先看这套组合里最容易上手的两兄弟：ECS和OSS。它们一个管计算，一个管存储，名字里都带“云”，但性格完全不同。

2.1 ECS到底是一台什么样的“电脑”

ECS的中文全称是弹性云服务器，英文是Elastic Compute Service。你可以把它理解为“一台永远开着机的电脑”，只不过这台电脑不在你的办公桌上，而是在某个数据中心里。

这台“电脑”能干什么？能登录、能装软件、能跑程序。你可以在上面安装JDK、Nginx、Redis、Tomcat，也可以随便跑一个Python脚本。它和你手边的笔记本没有本质区别，只是配置可以按需选：要几核CPU、几GB内存、多大带宽，选好就能开通，性能不够时还能在几分钟内升配。正因为可以随时扩大或缩小，它才叫“弹性”云服务器。

在实际架构里，ECS通常是“干活的人”。比如一个Web网站的后端服务、一个App的消息推送进程、一个定时任务调度器，这些都需要CPU和内存去算、去跑，它们就住在ECS里。文档里常见的“系统应用服务迁移ECS”，说的就是把原本跑在自建服务器上的业务程序，搬到云上的ECS里去继续跑。

需要注意，ECS本身也有系统盘和数据盘，但这和下面要说的OSS完全是两码事。ECS的系统盘是一块“云硬盘”，它跟着ECS走，你登录进去看到的C盘D盘就是它；而OSS是独立存在的存储服务，不依附于任何一台服务器。

2.2 OSS为什么是“仓库”而不是“网盘”

OSS的全称是Object Storage Service，对象存储服务。官方定位是“海量、安全、低成本、高可靠的云存储服务”。它最适合存放的，是图片、视频、文档、安装包这类非结构化文件。

为了讲清楚它，这里值得多花一点笔墨。OSS的“对象”是什么？你可以把每个文件看作一个“对象”，每个对象由三部分组成：文件名（Key）、用户数据（Data）、元信息（Object Meta）。其中元信息是描述文件的一组键值对，比如最后修改时间、文件大小，甚至你自己塞进去的自定义标签。

那“Bucket”又是什么？Bucket翻译过来叫“存储空间”，是装对象的容器。所有对象都必须属于某个Bucket，就像仓库里有若干排货架，每件货物必须放在某个货架上。Bucket有几个硬性规则：

• 名称在OSS范围内全局唯一，创建后不能改；
• 只能包含小写字母、数字和短横线（-），必须以小写字母或数字开头和结尾；
• 长度限制在3到63字节之间。

也就是说，“my-app-logs”合法，“My-App-Logs”不合法，“-my-app”不合法。下面这个示意代码，能帮你一眼看出哪些名字能过审：

# Bucket 名称命名规则检查 # 合法示例：my-app-logs、app-2024、data-bucket-01 # 非法示例：MyApp -> 包含大写字母 # 非法示例：app_2023 -> 下划线不允许 # 非法示例：-app -> 不能以短横线开头

对象（Object）也有命名限制：使用UTF-8编码，长度1到1023字节，不能以正斜线（/）或反斜线（\）开头。这里有个很多初学者理解不了的细节：你在OSS上看到“test1/test.jpg”这种名字，很容易以为它存在“test1”这个文件夹里，但OSS里根本没有文件夹的概念。

“test1/test.jpg”只是这个对象的一个完整Key，它和“a.jpg”在本质上没有任何区别，都是平铺在存储空间里的一个字符串。正因为这个设计，OSS可以支撑海量并发访问——它不需要一层层去翻目录，拿到Key就能直接定位文件。也正因为这个设计，如果你想把“test1”这个“目录”改成“test2”，OSS的真实操作是把所有以test1/开头的对象全部复制一遍改成新前缀，代价极高。

2.3 对象存储与传统文件系统的本质区别

很多人第一次接触OSS时，都会不自觉地把它当成一个“无限大的网盘”，想在上面做重命名目录、修改文件某一段内容的操作。这正是最容易踩坑的地方，原文里有一张非常直观的对比表，我把最关键的差异整理如下：

看到区别了吗？OSS的设计哲学是“存进去、读出来”，它不鼓励你做修改和目录搬家。如果你要改一个1GB文件的1个字节，OSS的做法是重新上传整个对象。因此把OSS直接当文件系统挂载是非常低效的，官方也明确不推荐；如果一定要挂载，也只建议做写新文件、删除文件、读取文件这三种操作。

另一点值得记住的是OSS的强一致性：你上传（PUT）一个对象成功后，它立刻就能被读到，不存在“写了一半”的中间状态；你删除一个对象成功后，它立刻就不存在了。底层数据还会做冗余存储，数据持久性号称不低于99.9999999999%，也就是传说中的“12个9”。通俗地说，数据存进OSS后，即使某个存储设施出问题，OSS也会自动用冗余数据把损坏部分重建出来。

2.4 Bucket、Object、Endpoint、AccessKey：四个词串起OSS的骨架

要真正在项目里用OSS，绕不开四个概念：Bucket、Object、Endpoint、AccessKey。前两个刚才讲过，这里补上后两个。

Endpoint是OSS对外服务的访问域名，不同地域的Endpoint不一样，内网访问和外网访问也不一样。比如杭州地域的外网Endpoint是oss-cn-hangzhou.aliyuncs.com，内网Endpoint是oss-cn-hangzhou-internal.aliyuncs.com。这个区别在实际迁移时非常重要：如果你的ECS也在杭州地域，ECS内网访问OSS就不收流量费，速度还更快；如果走公网访问，就要支付外网流出流量费用。

AccessKey简称AK，相当于你的“身份证加家门钥匙”，包含AccessKeyId和AccessKeySecret两部分。AccessKeyId用来标识你是谁，AccessKeySecret用来加密验证请求的签名，必须严格保密。它一旦泄露，别人就能用你的身份往OSS上传文件、删文件，相当于是仓库大门钥匙被人复制了。所以生产环境的AK要开最小权限，能用临时凭证（STS）授权就尽量别用主账号AK。

OSS还提供了三种存储类型：标准存储、低频访问存储、归档存储。标准存储适合频繁访问的数据，比如网站首页图片；低频访问存储适合每个月只访问一两次的数据，价格更低；归档存储适合要放半年以上的冷数据，价格最低。选错类型会怎样？该用低成本归档的用了标准存储，账单会明显偏高；该用标准存储的用了低频访问，每次读取都要额外付数据取回费。存储类型这件事，本质上是用“访问频率”换“存储成本”。

3. RDS：把数据库从“自建”换成“托管”，省下的不只是买机器的钱

讲完存储，再看这套组合里最需要“稳重”的角色——RDS。它的全称是Relational Database Service，关系型数据库服务。简而言之，RDS就是“你出钱，云厂商帮你养数据库”。

3.1 以前是自己抱数据库，现在是请专业团队看管

在RDS出现之前，团队要跑一个MySQL数据库，典型的做法是：买一台服务器，装好Linux，手动安装MySQL，配置数据目录，设置密码，再自己写脚本做定时备份。听起来不难，但真正上线后问题会接连冒出来：磁盘满了要自己扩，主从同步断了要自己修，半夜机器宕机要爬起来手动切换，版本升级要先在测试环境演练半天。

RDS把这一整套脏活累活接走了。你创建RDS实例后，拿到的是一个数据库连接地址，直接就能用。备份是自动的，高可用是内置的，监控告警是现成的，扩容也只需要在控制台点按钮。打个比方：以前你是自己雇了个账房先生，账房先生生病了你得亲自去替他记账；现在你外包给了一个专业的记账团队，他们有备用人员、有值班制度、有保险柜，你只需要每天看报表。

RDS支持的引擎很常见，比如MySQL、PostgreSQL、SQL Server。文档里提到的迁移场景，主要就是“MySQL数据迁移RDS”。

3.2 实例、数据库、账号是什么关系

很多第一次用RDS的人会卡在“实例、数据库、账号”这三个词的关系上。其实一句话就能理清：实例是一台独立的数据库服务器，实例下面可以创建多个数据库，账号则是用来连接和操作这些数据库的“通行证”。

类比一下，实例是一栋写字楼，数据库是楼里的不同公司办公室，账号是门禁卡。一张门禁卡可以只允许进A办公室，也可以同时进A、B两个办公室，全看管理员怎么授权。实际使用中，建议一个业务用一个账号，权限给到最小，比如只读账号就坚决不给写权限。

RDS实例本身具备高可用架构：主备两个节点，数据实时同步。主节点出故障时，备节点会自动顶上，应用几乎感知不到切换过程，这就是“产品高可用”带来的价值。对业务来说，数据库连接地址不变，但背后已经完成了一次故障转移。

来看一个前后对比的连接串示例。自建MySQL时，连接地址通常长这样：jdbc:mysql://192.168.1.10:3306/order_db；使用RDS后，连接地址变成：

-- 自建 MySQL 连接串（需要自己维护主从、备份、监控） jdbc:mysql://192.168.1.10:3306/order_db -- RDS 连接串（高可用、备份、监控全部托管） jdbc:mysql://rm-xxxxxx.mysql.rds.aliyuncs.com:3306/order_db

注意看，RDS给的是一个带域名的地址，而不是裸IP。这是因为RDS实例背后有VIP（虚拟IP）和主备节点，如果给你一个物理IP，主备切换后IP可能就变了，域名地址则始终不变，应用不用改配置。

3.3 从MySQL迁移到RDS时最容易忽略的三件事

把本地或ECS上的MySQL数据迁到RDS，听起来无非是“导出再导入”，但实际操作中容易忽略三件事，如果处理不当，迁移完成后才会发现业务悄悄出错。

第一是字符集。很多老数据库表用的是latin1或其他字符集，RDS默认可能是utf8mb4。迁移前不统一字符集，中文数据导入后直接变成乱码，而且这种乱码很难通过简单修改恢复。迁移前先查一遍所有表的字符集，能和目标端保持一致就尽量一致。

第二是账号权限。迁移完成后，原系统的数据库账号密码可能和RDS不一致。文档里特别强调，迁移对数据库账号的权限有要求，比如源库账号需要具备读取权限，目标库账号需要具备写入权限。如果权限不够，传输过程中会出现“读不出来”或“写不进去”的情况。

第三是白名单。RDS实例默认有访问白名单，只有白名单内的IP才能连接数据库。很多人在迁移后遇到“连接超时”，排查半天才发现是ECS的IP不在RDS白名单里。安全起见，白名单应该精确到ECS的私网IP，而不是图省事放行0.0.0.0/0，否则数据库等于裸奔在公网上。

3.4 RDS为什么不替代OSS

这里需要提前埋一个引子，因为后面专门有一章讲易混概念：RDS存的是结构化数据，OSS存的是非结构化文件。用户在OSS上看到的是图片、视频、文档，在RDS里看到的是订单表、用户表、商品表。两者的查询方式也完全不同——RDS用SQL去筛选、排序、关联多张表；OSS则是给你一个URL，你把整个文件拿走，它不管文件里面是什么。

所以，一个典型的电商系统里，商品图片放在OSS，商品名称、价格、库存数量放在RDS。前端页面先通过接口从RDS查出商品信息，其中图片地址指向OSS，再由浏览器去OSS加载图片。两者各司其职，谁也替代不了谁。

4. SLB：流量入口的交通警察，凭什么让多台ECS不吵架

这套组合里最有“存在感”的通常是SLB，因为用户请求第一个遇到的就是它。SLB全称Server Load Balancer，负载均衡服务。一句话定义：它站在所有后端服务器前面，负责把进来的请求均匀地分发给多台服务器。

4.1 为什么多台ECS不能直接暴露给用户

假设你的系统有两台ECS，都跑着同一个网站服务。如果不引入SLB，最原始的做法是把两台ECS的公网IP都解析到域名里，让用户随机访问其中一台。这就是所谓的DNS轮询。

但DNS轮询有个致命问题：它不知道某台服务器是不是还活着。如果其中一台ECS宕机了，DNS照样会把一部分用户引导到那台宕机的机器上，结果就是这些用户看到“网站打不开”，而另外一半用户却一切正常。更麻烦的是，重启、发版、扩容这些日常操作需要频繁修改DNS解析记录，而DNS解析有缓存，生效要等很久。

SLB解决的就是这个问题。它是所有流量的统一入口，后端挂几台ECS都行。SLB会持续对后端服务器做健康检查，发现某台ECS不响应了，就自动把它从分发列表里摘掉，剩下的请求全部转发给健康节点；等到这台ECS恢复后，又自动加回来。这一切都是实时发生的，不需要人工干预。

用餐厅来类比，SLB就是门口那个拿对讲机的迎宾。客人来了，迎宾看看哪个桌子空着、哪个桌刚收拾好，就把人往那边带；某个区域暂时不能接待，迎宾就自动跳过它。如果没有迎宾，客人自己往里冲，就可能出现一边挤爆、一边空着的局面。

4.2 监听器、后端服务器、健康检查是怎么配合的

SLB的核心由三部分组成：监听器（Listener）、后端服务器（Backend Server）和健康检查。

监听器负责“听什么、怎么转发”。你需要告诉SLB：监听哪个端口（比如80或443）、用什么协议（HTTP、HTTPS、TCP）、把流量转发给哪组后端服务器。一个SLB实例可以配置多个监听器，比如一个监听80端口处理HTTP，一个监听443端口处理HTTPS，流量互不干扰。

后端服务器就是真正处理请求的ECS。你可以把多台ECS加入同一个后端服务器组，SLB会按权重分发流量。权重越高分到的请求越多，这个参数在灰度发版时特别有用——新版本先挂一台低权重ECS，观察没问题后再把权重调高。

健康检查是SLB的“体检医生”。常见配置是让SLB每隔几秒向后端服务器发起一次探活请求，比如访问一个固定的健康检查路径（/healthz），如果连续几次没收到健康响应，就把这台服务器标记为异常，不再转发新请求。

下面是一份简化的配置示意，方便你理解监听器和后端服务器的关系：

{ "listener": { "protocol": "HTTPS", "port": 443, "backendGroup": "web-servers", "healthCheck": { "path": "/healthz", "interval": 5, "unhealthyThreshold": 3 } } }

这里的含义是：SLB监听443端口的HTTPS请求，转发给名为web-servers的后端服务器组，每5秒检查一次/healthz路径，连续3次失败就判定后端服务器不健康。健康检查这条路看起来简单，却在生产环境里救过无数次命——它把故障机器从流量中摘除，让用户始终访问到健康的服务器。

4.3 会话保持和证书管理：两个容易被忽视的细节

流量平均分配给多台服务器后，会带来一个新问题：用户登录状态怎么办？

假设用户第一次请求被分到了ECS-A，登录信息写在了ECS-A上；刷新页面后，SLB把第二次请求分到了ECS-B，ECS-B没有这个用户的登录信息，用户就以为自己“被登出了”。这就是为什么SLB提供“会话保持”功能，也叫会话保持或粘性会话。开启后，SLB会给同一个来源的用户尽量转发到同一台后端服务器，从而保证登录状态不丢。

不过要注意，会话保持也是一把双刃剑。如果某台ECS流量特别大，而大量用户都被粘在这台机器上，就可能出现这台机器过热、其他机器闲着的情况。所以，更现代的做法是让应用层把会话状态存到Redis这类集中式缓存里，这样任何一台ECS都能处理任何用户的请求，SLB就可以纯粹按负载分发，不必依赖会话保持。

证书管理则对应HTTPS。传统方案里，每台ECS都要部署一份SSL证书，换证书时要挨个登上去更新。SLB可以把证书统一管理，在SLB这一层完成HTTPS解密，再把明文HTTP请求转给后端ECS，这就是常说的“SSL卸载”。后端服务器因此省去了加解密开销，证书也只需要在SLB上维护一份。

4.4 SLB在实际架构中的位置

回到整套架构来看，SLB永远站在最前面。用户访问域名时，DNS把域名解析到SLB的公网IP；SLB收到请求后，根据监听规则将请求转发给后端的ECS；ECS处理完业务逻辑，需要图片时去OSS取，需要数据时去RDS查。整套链路是“用户→SLB→ECS→OSS/RDS”，请求入口只有一个，后端却可以有多台ECS，数据库和存储则稳定地待在后方。

这种设计带来的直接好处是扩容变得非常简单：活动流量涨了，新开两台ECS加入后端服务器组，SLB自动开始分发流量，全程不需要改用户访问的域名，也不需要动数据库。这也就是“弹性伸缩”在日常架构中的真实落地。

5. 易混概念：存储、计算、数据库、流量，这四件事别混成一锅粥

前面把四个服务分别讲了一遍，但真正让初学者头疼的是它们之间的边界。这一章专门说说最容易被搞混的四个误区，每个都按“哪里容易混、为什么混、怎么区分”来讲。

5.1 误区一：OSS和云硬盘都能存文件，用哪个都行？

这是最常见的问题。OSS和ECS的系统盘/数据盘确实都能存文件，甚至都可以在上面放图片，但两者的本质完全不同。

为什么混：因为从使用者角度看，都是“往一个空间里放文件，再把文件读出来”。

怎么区分：ECS的云硬盘是给ECS做本地存储用的，它必须挂载到一台ECS上才能访问，你登录到ECS里看到的路径是/dev/vda1或者C盘。云硬盘适合存操作系统、应用程序、临时文件，它强调低延迟和随机读写。OSS则是独立存储服务，不跟随任何一台ECS，通过HTTP RESTful API访问，任何设备只要能联网就能读写。OSS适合存海量图片、视频、备份文件，强调海量、低成本、高可靠。简单记：云硬盘是“电脑里的硬盘”，OSS是“网上的仓库”。如果你访问一个文件还需要走公网URL，那多半用OSS；如果你只是让某台ECS上的程序快速读写本地文件，那用云硬盘。

5.2 误区二：RDS和自己装的MySQL不都是MySQL吗？

这也是高频误解。看到RDS的引擎是MySQL，就以为RDS和自己ECS里装的MySQL是一回事，甚至觉得没必要为此付费。

为什么混：两者用起来确实很像，都支持SQL语句，都监听3306端口，连接方式都是JDBC串。

怎么区分：自建MySQL是一套需要“你全权负责”的数据库系统，装在哪里、磁盘多大、怎么备份、怎么做主从，全部自己操心；RDS则是一套“托管数据库服务”，底层的主从架构、自动备份、故障切换、监控告警都是云厂商负责的。自建MySQL好比你自己买了个保险柜，钥匙自己保管，保险柜坏了自己修；RDS是银行保险箱服务，银行负责安保、消防、维修，你只管把值钱的东西放进去。更进一步说，RDS的实例本身是主备高可用架构，你拿到的永远是一个稳定的域名地址；自建MySQL想达到同样的可用性，至少得自己搭一主一从，再写一套切换脚本，运维成本不可同日而语。

5.3 误区三：SLB和DNS轮询都能分流，有SLB就不用理解DNS？

SLB和DNS轮询都能把用户请求分散到多台服务器上，但它们的健壮性有天壤之别。

为什么混：因为它们做的事情表面上都是“把流量分给多台机器”，名字里也都带“负载均衡”的影子。

怎么区分：DNS轮询发生在“域名解析”阶段，它只负责让不同用户解析到不同IP，一旦IP对应的服务器宕机了，它不知道也不会处理，用户访问就会失败。SLB发生在“请求转发”阶段，所有请求先到SLB，再由SLB实时分发给后端服务器，并且带有健康检查，能自动剔除故障节点。打个比方，DNS轮询像是小区门口贴了个告示“送水的请去1栋、2栋、3栋”，不问哪栋楼今天没人；SLB则是门卫亲自看监控，发现2栋没人就只往1栋和3栋带路。在实际架构里，DNS一般只解析到SLB的IP，SLB再负责后端多台ECS的分发，两层各司其职。

5.4 误区四：OSS的标准存储、低频访问、归档存储只是“套餐不同”？

这种理解不算全错，但容易忽略一个关键差异——数据取回的代价。

为什么混：因为对用户来说，上传和下载的方式完全一样，都是通过API，只是控制台里选的存储类型不同。

怎么区分：标准存储适合频繁访问的数据，随时取用，没有取回费用；低频访问存储适合每月访问一两次的数据，存储单价便宜，但每次取回数据要额外支付取回费；归档存储单价最低，但取回数据需要等待解冻，可能要等几分钟甚至更久，并不适合做在线访问。简单判断标准是：这份数据下次访问会在什么时候？如果下一秒就要用，用标准；一个月后用一次，用低频；半年后才可能用，且能接受等待，用归档。选错存储类型不会丢数据，但账单会让你留下深刻印象。

5.5 误区五：ECS上可以跑数据库，所以RDS没必要买？

这个误区通常是“省钱党”的思维：既然ECS能干所有事，为什么还要单独买RDS？

为什么混：ECS确实能安装MySQL并稳定运行，小型项目的确可以这样做。

怎么区分：关键在于可用性和运维成本的权衡。自建数据库在ECS上，遇到磁盘满、主从延迟、数据损坏、实例宕机等问题，都要自己处理，处理时间通常是小时级别；RDS把这些问题包装成“自动处理”的托管能力，故障切换时间是秒级。对核心业务来说，宕机一小时的损失往往远超一年RDS的费用。什么时候可以不用RDS？后面一章会专门说。这里只需要记住：ECS上的MySQL适合开发测试、低并发场景；RDS适合业务数据不能丢、不能长时间中断的生产系统。

6. 这一套组合拳什么时候该用：从一次系统迁移看边界

理解了四个服务的职责，最后一个问题是：我到底该不该用这一整套？不是所有系统都需要SLB-ECS-OSS-RDS全家桶，过早引入只会增加复杂度和成本。

先看一个典型的适用场景。某公司原来有一套自建系统，跑在一台物理服务器上：图片文件存在本地磁盘，数据库是服务器上的MySQL，Web应用也跑在同一台机器上，用户直接通过服务器IP访问。刚开始人少没问题，后来用户量上来，磁盘快满了，数据库查询开始变慢，更尴尬的是，一旦服务器重启，整个系统全部不可用。系统迁移时就可以按这套组合拳来做：

第一步，系统文件资源迁移到OSS。把原来挂在HTTP服务下的图片、文档等非结构化文件，批量上传到OSS的Bucket里，应用代码中把文件访问地址改为OSS的URL，同时开启图片处理服务，用缩略图和水印功能替代原来自己写的图片处理逻辑。

第二步，MySQL数据迁移到RDS。通过数据传输工具，把原服务器的数据库迁移到RDS实例，应用连接串从原来的IP改为RDS提供的域名地址，账号权限、字符集、白名单都提前检查一遍。

第三步，系统应用服务迁移到ECS。在ECS上安装JDK、Nginx、Redis等运行环境，把Web后台、移动端服务等应用部署上去，数据库地址指向RDS，文件路径改为调用OSS。

第四步，部署SLB。把多台ECS加入SLB后端，配置监听器和健康检查，域名解析到SLB，原来的单点入口变成高可用入口。这套调整完成后，每一层的职责都清晰了：SLB负责引入流量，ECS负责计算，OSS负责文件，RDS负责数据。

反过来，边界也很重要。如果只是个人学习、内部工具、日访问量不到几百的系统，一台ECS加一个自建MySQL完全够用，没必要上SLB和RDS。给一个小网站配三个SLB监听器、两组后端服务器、两套白名单，运维复杂度反而会把人劝退。以下情况建议慎重使用全家桶：

• 系统几乎没有并发，一台服务器常年CPU使用率不到10%；
• 数据量很小且不增长，一个SQLite文件就能搞定；
• 团队没有专人负责云资源管理，开通了一堆服务却没人知道怎么维护。

那以后我形成了一个习惯：任何一个系统要上云，先在纸上画一张“四件套关系图”，标清楚哪台机器跑计算、哪类文件进仓库、哪套数据进数据库、谁在门口分发流量。这张图画不明白，迁移就一定会翻车；画明白了，后面每个步骤都只是按图施工。希望这篇能帮你建立起这套架构的基础认知，下次看到架构图上的那串缩写，不会再觉得它们是一团乱码。

本文还有配套的精品资源，点击获取