第一次打开阿里云控制台，很多人会被产品列表晃住。ECS、OSS、RDS、SLB、VPC 一排排摆着，名字都认识，关系却说不清。其实按层看下来，这些产品基本能各自归位。我们从底层往上捋，最后用一个电商的例子把它们串起来。
底层：飞天和自研基础设施
阿里云的底座是一套大规模分布式系统，它的操作系统一般叫飞天，负责把大量服务器的计算、存储和网络资源统一调度。在这之上，阿里云又做了自研的服务器、分布式存储和网络，目的是提高资源利用率，并让单点故障的影响范围尽量小。
平时使用者不会直接碰这一层，但它决定了上层服务的稳定性和弹性上限。知道这一点，就能理解为什么扩容在云上能很快完成。
资源层：地域、可用区和网络
再往上是资源的组织方式。这一层通常在架构设计的最开始就要定下来，后面改起来成本最高。
- 地域（Region）指华北、华东、华南这类区域，决定数据放在哪里。它直接影响访问延迟，也关系到合规要求，比如某些行业数据必须留在境内特定地区。
- 可用区（Zone）是同一地域内相互独立的机房单元。关键服务要跨可用区部署，否则一个机房出问题，整个业务都会跟着断。
- 专有网络 VPC是你自己的逻辑隔离网络。子网怎么划、路由怎么配、安全组开哪些端口，都在这里决定，它是整套架构的网络边界。
不少线上事故，根源往往是所有实例挤在同一个可用区、同一个子网里。局部一出故障，全部一起受影响。这一层规划得当，后面的麻烦能少很多。
产品层：计算、存储、数据库和中间件
产品层是日常用得最多的部分，按职能大致可以分成几类。
- 计算包括云服务器 ECS 提供的基础算力、容器服务 ACK 托管的 Kubernetes，以及适合事件触发轻量任务的函数计算。
- 存储里，对象存储 OSS 适合放图片、视频、备份这类非结构化数据；块存储 EBS 挂在 ECS 上，用作系统盘或数据盘。
- 数据库方面，关系型数据库 RDS 和 PolarDB 覆盖主流引擎，Redis 版主要用来做缓存和会话。
- 接入与分发由负载均衡 SLB 负责分流，CDN 把静态资源推到离用户更近的节点。
- 可观测与安全包括云监控、日志服务 SLS 和访问控制 RAM，是运维和权限的基础。
选产品时别急着问哪个最好，先问它管什么。计算节点不适合存文件，对象存储不跑业务逻辑，数据库只放结构化数据。职责分开了，扩容和排障才有章法。如果一台 ECS 上既跑服务又存用户上传的图片，等磁盘满了再迁移，会很被动。
案例：一家中型服装电商的上云架构
假设一家服装电商，大促时的访问量是平时的好几倍，它的架构大致可以这样搭。
- 商品图片和视频放进 OSS，经 CDN 分发，源站压力会小很多。
- 前端流量通过 SLB 分到多个可用区的 ECS 或 ACK 集群，业务服务按负载自动伸缩。
- 订单和用户数据写入 PolarDB，商品详情读多写少，放在 Redis 里做缓存。
- 秒杀请求先进入消息队列排队，再由后端异步处理，避免瞬间写入把数据库打垮。
- 所有实例放在 VPC 的私有子网里，只有 SLB 对外开放，数据库只允许应用子网访问。
- 在云监控和 SLS 上设好告警，大促前做一次压测，用压测结果确定扩容阈值。阈值如果是凭经验拍的，大促当天很可能不够用。
这套方案能跑起来，靠的是每一层的边界都清楚，产品堆得多并不等于稳。大促结束后，ECS 和 ACK 节点可以按需缩回来，成本也跟着降下来。按需付费、随用随缩，正是云上相对自建机房最实在的好处。
落地时的几条建议
- 先画出地域、可用区和 VPC 的规划，再去挑具体产品。网络结构一旦定型，后期调整会很痛苦。
- 权限从一开始就走 RAM，给子账号和角色分配最小权限。别让团队成员长期拿着主账号 AK 直接操作。
- 资源标签和成本分摊同步设计。标签打好了，月底才能按项目或部门算清账。
- 关键业务做跨可用区容灾，并定期演练恢复流程。没演练过的备份，出事时大概率用不上。
阿里云结构并不复杂，它就是从资源到业务一层层搭起来的。先把分层想清楚，选型和扩容都会顺很多。
