很多团队说要上云，做的却只是把虚拟机从机房搬到阿里云。机器换了位置，单体结构没变，扩容还是整体加机器，故障还是会一起倒。阿里云架构要解决的，是把系统拆成能独立伸缩、独立隔离故障的几个部分。下面按四层看一遍，再说说落地时容易踩的坑。
为什么单体改造要先想清楚容量和故障
以前在机房里，容量规划几乎等于买机器。采购周期动辄几周，扩容要提前安排，峰值一到，团队只能凭经验多备几台。上云之后，资源可以按需申请、按量计费，问题随之变成三个：资源怎么跟着业务波动走，故障怎么关在局部不蔓延，每次发布出了问题怎么快速回滚。
这三件事能不能分开处理，决定了上云后的架构好不好用。计算、存储、网络、数据库、中间件和安全分别由不同产品承接，团队可以按业务阶段逐步引入。没必要为了上云推倒重来，先挑一个最痛的环节动手，风险小，也更容易看到效果。
典型分层与核心组件
一套比较完整的云上架构，一般分成接入层、服务层、数据层和支撑层。每层职责清楚，改造时才好判断先动哪里。
接入层
- 负载均衡（SLB/ALB）：流量入口的第一道分发。一定要配置健康检查，否则某台实例挂了，仍会有部分请求持续失败。
- API 网关：鉴权、限流和协议转换放在这里统一处理。如果每个微服务各写一套鉴权，改一次策略就得逐个服务发布。
- WAF 与 DDoS 防护：在入口过滤明显的恶意请求，减轻后端压力。它不能替代业务层的参数校验，两者要一起做。
服务层
服务层通常用容器服务 ACK 运行微服务，搭配服务注册、配置中心和链路追踪。流量波动明显的业务，可以用弹性伸缩组或 Serverless 容器按指标自动扩缩，高峰时响应跟得上，低谷时资源也不会白白空转。扩缩容阈值最好结合压测结果来定，直接套默认值往往不准。
数据层
数据层选得对不对，往往决定系统能扛多大的流量。交易类数据放在 PolarDB 或 RDS 这类关系型数据库里，缓存用 Redis 版，海量日志和行为数据更适合放进 SLS 或 MaxCompute，做离线或准实时分析。数据量涨起来之后，读写分离、分库分表、冷热分层是常见做法，但每一种都会带来跨库事务和查询复杂度的问题，最好在数据量真正上来之前就想清楚。
支撑层
支撑层包括可观测性（云监控、ARMS）、CI/CD 流水线、密钥管理和权限体系（RAM）。不少团队业务上线后才补这一层，等出了故障才发现没有日志和指标可查，排查成本反而更高。设计初期就把它列进去，哪怕先做最简版本，也比事后补省事。
案例：某电商平台的大促改造
某中型电商平台原先是单体应用加自建 MySQL。每年大促前要临时给数据库扩容，活动结束后资源又长期闲置，成本和风险都压在运维身上。团队在阿里云上分三步改造：
- 把订单、商品、用户拆成独立服务，部署到 ACK 集群，通过 SLB 按服务做流量隔离。拆分时先从边界最清楚的模块开始，订单链路放在最后动。
- 交易库迁移到 PolarDB 集群，查询流量交给只读实例承接；热点商品数据放进 Redis，命中率维持在较高水平。
- 大促前用弹性伸缩提前扩容，活动结束后自动回收。下单链路配上限流和降级，压力出现时优先保住核心交易。
改造后，大促的资源准备从几周缩短到几小时，数据库故障的影响范围也从整库缩小到单个分片。值得留意的是，这些效果来自几个组件配合，只换数据库或只加缓存，很难得到同样的结果。
落地时的几个提醒
- 先把非功能指标写清楚：可用性目标、延迟要求和预算上限，会直接决定做多可用区还是多地域部署。目标没定，架构容易过度设计，或者能力不够用。
- 拆分别过头：服务数量要和团队规模、交付节奏对得上。比如一个五六人的小组，如果要维护几十个服务，联调和发布花的时间可能比业务开发还多。
- 成本要有人盯：给资源打标签，设置预算告警，用好节省计划。弹性只有在资源真正被回收时才省钱，否则只是把闲置换了个说法。
- 容灾要实际演练：跨可用区部署和数据库备份恢复，要定期真正跑一遍。只写在文档里的恢复方案，出事时基本派不上用场。
回到最初的问题，阿里云架构的关键是把业务能力拆成边界清楚、能独立伸缩的几块，再为每一块选合适的产品。改造时不必一次做完，选一个最痛的点切入，验证有效后再往下推进，通常比整体重构更稳妥。
