很多小团队第一次上云，看到控制台里几十个产品，往往不知道从哪下手。实际支撑大多数网站、小程序和内容平台的，通常只是三个基础产品：云服务器 ECS、关系型数据库 RDS 和对象存储 OSS。圈子里常把它们叫作阿里云三剑客。这三样用顺了，业务就有了一个可靠的底座。
三者各管什么
ECS 跑程序，RDS 存结构化数据，OSS 存图片、视频、安装包这类文件。职责基本不重叠，放在一起刚好能覆盖一个完整应用的常见需求。
小团队用云最直接的好处，是不用先买硬件，也不用自己养机房。访问量涨了，升配或加实例就行；量降下来，把规格调小，也不必为闲置的机器持续付费。
案例一：独立站从单机搬到三剑客
一位朋友做手作饰品，最早把网站、数据库和商品图全放在一台旧服务器上。图片占掉七成硬盘，大促时页面明显变慢，备份靠手动拷贝，人一忙就忘。
搬迁思路并不复杂。网站程序先部署到 ECS，这台机器只负责计算和页面渲染。订单、用户、商品信息迁进 RDS，开启自动备份，每天一次。商品图全部上传到 OSS，前端通过绑定的域名访问，原服务器的磁盘压力一下子轻了。
搬完之后，他的感受很具体。大促期间不再因为图片请求把服务器拖垮。有一次误删了一张表，从备份里几分钟就恢复了。扩容也简单，只改 ECS 配置就行，不用再动文件。
别把所有东西塞进一台机器
不少人上云后，习惯把所有东西都放进 ECS 的系统盘，上传的文件、日志，甚至数据库本身。短期确实省事，但服务器一出故障，数据抢救起来很费劲，扩容也容易被卡住。
比较稳的做法是守住三条线：
- 计算和存储分开：ECS 上只放程序代码，代码最好放在版本库里。机器坏了，可以新开一台重新部署。
- 结构化数据进 RDS：用户、订单、配置这类需要事务和查询的数据，交给托管数据库。若自己在 ECS 上装数据库，补丁、备份、主从切换都得自己管。
- 文件进 OSS：图片、视频、下载包统一放对象存储，访问量大的再配合 CDN。别把上传目录直接建在系统盘下面。
三条都做到，服务器就成了随时可以替换的计算单元，数据和文件则落在更可靠的托管服务里。
案例二：内容团队的图片与备份
另一个小型内容团队，每天要发几十篇图文，素材增长很快。最初用 ECS 挂载的云盘存图，磁盘很快不够用，扩容频繁，还因为误操作丢过文件。
后来他们把素材库整体迁到 OSS，开启版本控制和生命周期规则。三十天没被访问的原图自动转为低频存储，成本降了不少。数据库单独放在 RDS，定期备份到另一个地域的 OSS 桶，留一份异地副本。
这套做法的关键，是提前想清楚三件事：存什么、存在哪、留多久。等出了问题再补，通常代价更大。
上手前先处理这几件事
第一，网络和权限先收紧。RDS 不要直接暴露在公网，只允许 ECS 所在的内网访问。OSS 桶如果设成公开读写，很容易被人刷流量或篡改文件，权限按实际需要分配。数据库也别长期使用主账号，给应用单独建一个账号，只授予它需要的库和操作。
第二，备份要真的试过。很多团队以为开了备份就万无一失，却从没演练过恢复。建议每个月在测试环境完整跑一遍恢复流程，记下耗时，确认数据能用，心里才有底。
第三，账单要常看。三者计费方式不同：ECS 按规格和时长，RDS 与存储容量和规格有关，OSS 则涉及存储量、请求次数和流量。具体价格以阿里云官网最新公示为准。每月花几分钟看一次账单，通常很快就能找出最费钱的那一项。
收尾
三剑客没有什么神秘之处。它们把服务器、数据库和文件存储变成了按需取用的基础能力。团队不必一开始就上复杂架构，先把计算、数据和文件各归其位，大部分问题就能解决。业务长到一定规模，再考虑负载均衡、缓存、容器这些产品，会从容得多。
