企业上云现在要关心的，已经是怎么用得稳、用得省。架构选得好不好，直接决定大促时系统扛不扛得住，账单能不能控住，业务要改版时改起来累不累。所以做阿里云架构规划，先想清楚哪些模块该先上，比一上来就堆产品更实际。
先把架构分成四层看
拿到一个阿里云架构的需求，我习惯从四层去拆。这四层各管各的事，但彼此要靠标准的接口衔接，不然后面改起来会很费劲。
- 基础资源层：ECS、VPC、SLB 这些是底座。VPC 网段要提前规划好，后面再改基本等于重建，别图省事随便给一个 10.0.0.0/8 的大段就用。
- 平台服务层：RDS、OSS、消息队列、ACK 这类托管服务。能用托管就尽量用托管，自己维护 MySQL 主从和 Kafka 集群的人力成本，通常比多付的那部分钱高得多。
- 应用架构层：决定是单体、微服务还是服务网格。团队不大、业务还在摸索的时候，单体拆成几个模块部署往往就够，不必一开始就上全套微服务。
- 治理运营层：监控告警、日志审计、权限和成本分析。这一层最容易被往后拖，等出了事故或者账单吓人才想起来补，所以建议第一天就把基础监控和预算告警配上。
电商大促：弹性是怎么落地的
有个中型电商客户的情况很典型。他们平时流量只有大促峰值的十分之一左右。早期用固定规模的服务器，结果两头都不舒服：大促时页面卡，平时机器闲着烧钱。
改造时他们主要做了三件事。第一，把商品、订单、支付拆开，分别跑在 ACK 集群里，每个服务按自己的指标设伸缩规则。订单服务看的是 CPU 和待处理请求数，商品服务更多看查询 QPS，不要所有服务共用一条规则。第二，前端流量经 SLB 分发到多个可用区，数据库用 RDS 高可用版，再加只读实例做读写分离。读写分离还要注意一个地方，刚下单的用户如果马上查订单，读到的可能是从库的旧数据，这类页面要强制走主库。第三，秒杀接口在应用层加限流和排队，热点库存放到 Redis 里。不做这一层，库存扣减的请求会直接把数据库打穿。
上线之后大促期间整体比较平稳，活动结束资源也会自动缩回去。我觉得这个案例值得看的，是他们把”弹性”从一句口号变成了几条能执行、能验证的规则，用了多少产品反倒没那么重要。
数据链路：报表为什么慢
另一类常见需求来自数据分析。某制造企业的订单、设备和质检数据分散在好几个业务库里，每次汇总报表要跑几个小时，业务部门早上要的数，中午才拿到。
他们的调整思路是分层。业务数据通过同步工具写进 OSS 数据湖，离线计算交给 MaxCompute，核心指标算完写进云数据库，报表系统直接查这份结果。设备告警这类实时指标不走离线链路，而是经消息队列进入流式计算。这样离线分析和在线服务互不抢资源，报表延迟从小时级降到了分钟级。需要提醒的是，同步工具的增量策略要先想好，否则全量同步会把业务库拖慢，这一点在方案评审时经常被忽略。
安全要在设计时就放进去
安全能力如果等上线后再补，通常会补得很被动。这几件事最好在设计阶段就定下来。
- 用 RAM 管账号和权限，按最小权限给。开发人员的账号不要顺手给上 AdministratorAccess，等哪天误删了生产资源，那时候再收回来会很麻烦。
- 业务部署在专有网络里，用安全组和网络 ACL 限制访问范围。数据库不要开公网地址，这条听起来基础，但实际检查时仍然经常踩到。
- 密钥和数据库密码交给密钥管理服务，不要明文写进代码仓库。仓库一旦公开，泄露的代价往往比想象中大。
- 开启操作审计和日志留存，留存周期要按合规要求来定，不要凭感觉设一个数字。
还要说明一点：工具只能提供基础能力，安全策略能不能落地，还要看变更审批和权限回收这些组织流程。流程没跟上，再好的配置也会慢慢松掉。
成本怎么排，先看这三件事
- 规格匹配：先看一到两周的监控数据，CPU 和内存长期低于三成的实例，就该降配。很多团队上线时按最坏情况配的规格，之后很少回头看。
- 弹性和预留搭配：基础负载用包年包月或预留实例，价格更低。波动的部分交给按量付费和弹性伸缩。先把基础盘的量估准，比一上来就全按量或全包年都划算。
- 存储分级：超过三个月没人访问的数据，转到低频或归档存储，并配好生命周期规则。日志和备份类数据最容易在这里悄悄积累成一笔大账单。
先从哪里开始
建议先把业务的关键路径和可用性目标列出来，比如下单链路要做到什么程度不能挂，报表允许延迟多久。目标清楚了，再去选模块。第一步可以只上最小可用的一套，跑一段时间，用监控数据验证假设，再决定要不要扩。架构不是一次定完的，它会跟着业务一起变。
这篇文章讲的是思路，具体方案还是要结合企业的业务量、合规要求和预算来算，照抄很难直接用。
