很多人第一次用阿里云ESC（弹性计算服务，Elastic Compute Service），是为了先把网站或业务跑起来。实例开得快，用起来像一台随时能开关的虚拟机，配置随便选一个似乎也能用。真正上线后才发现，选型、网络、存储和计费都会影响稳定性和账单。这篇文章从几个常见场景出发，说说选型和弹性伸缩该怎么配，以及哪些地方最容易出问题。
实例选型，先看负载类型
选机器时，不少人会直接挑最高配置，图个保险。结果是钱花了，CPU却长期闲着。更稳妥的做法是先想清楚这台机器主要干什么。
- 通用型：适合Web应用、中小型数据库和开发测试环境，CPU与内存比例比较均衡，很多业务先从这里起步。
- 计算型：适合视频转码、批量计算、游戏服务端这类吃CPU的任务。如果监控里内存常年很空，而CPU经常跑满，就该考虑它。
- 内存型：适合缓存服务、大内存数据库和数据分析。这类场景的瓶颈通常在内存容量，而不是核数。
规格族会随代际更新，具体型号和价格以阿里云官方文档的当前说明为准，不要凭印象选。同一规格族里的不同规格，性能基线和突发能力也可能有差别。上线前用自己的业务流量压一轮，比只看参数表更可靠。
扩容别靠人盯着做
某本地生活电商团队的小程序，平时访问量不大，但每逢周末促销，流量会在短时间内涨到平日的五六倍。他们最早在ESC上手动扩容，大促前一天加机器、装环境，既慢又容易漏步骤。
后来他们做了两件事。第一，把应用打成标准镜像，配合弹性伸缩（ESS）建立伸缩组，按CPU使用率和请求数自动增减实例。第二，前端接入负载均衡，后端实例注册到服务器组里，新实例启动后直接接收流量，不用人工挂载。
改完之后，大促扩容从半天缩短到几分钟，夜间低峰时实例数会自动回落，月度计算成本也降了不少。这个例子说明，ESC本身只是资源单元，效果来自它和负载均衡、伸缩规则之间的配合。只换更大的机器，解决不了这类问题。
网络和安全组，默认配置不等于安全
安全组是ESC最基础的访问控制，也是最容易被忽略的一层。常见情况有两种：为了调试方便，把22号（SSH）或3306号（MySQL）端口对全网开放；或者规则加了就不管，几年下来留着一堆没人认得的放行记录。
可以按下面几条收紧：
- 只开放业务真正需要的端口，来源尽量限定到具体IP段，不要直接写0.0.0.0/0。
- 数据库和缓存放在内网，不绑定公网地址。需要远程运维时，走堡垒机或VPN。
- 每个季度过一遍安全组，把无人认领的规则删掉。
- 人员访问使用RAM子账号，权限按角色分配，别让多人共用一个高权限账号和密钥。
有家初创公司测试时临时开放了数据库端口，后来忘了关，数据库很快就被外部扫描，并遭到爆破尝试。之后他们把安全组变更纳入流程，每次放行都要写明用途和截止时间，类似问题就再没出现过。临时放行最容易变成长期风险，这一点值得记住。
系统盘和数据盘分开，快照别只做一次
系统盘放操作系统和应用，数据盘放业务数据，两者最好分开看。数据库这类有状态的服务，把数据目录放在独立数据盘上，后续迁移、扩容和回滚都会轻松很多。数据盘再配一套定期快照，误删文件、升级失败或者中了勒索软件时，就能较快回到之前的状态。平时看不出价值，出事时才知道值不值。
快照频率也不必一味往高调。应该根据业务能接受丢失多久的数据（RPO），以及能停机多久（RTO）来定。频率过高，快照数量和费用都会上涨；保留周期拉得过长，同样会悄悄推高账单。定好策略后，最好真做一次恢复演练，否则快照只是存在那里，并不等于可用的备份。
计费模式，按负载组合
ESC常见的计费方式有包年包月、按量付费和抢占式实例。长期稳定运行的核心服务，包年包月通常更划算。临时测试、压测和批处理任务用按量付费，用完即释放，不会留下闲置成本。容错性较好的批量计算可以考虑抢占式实例，价格通常便宜不少，但它随时可能被回收，任务必须能中断后重试，并支持断点续跑。
不少团队的做法是混合使用：核心服务用包年包月兜底，波动部分由按量实例补充。这样预算有底，业务高峰也不至于手忙脚乱。具体比例没有标准答案，看看历史流量的波峰和波谷差多少，大致就有数了。
ESC本身不难上手，难的是把它放进整体架构里想清楚。选型先看负载，网络先守住边界，存储先留好退路，计费按负载组合。这几件事理顺了，ESC才算稳定、可控，也能随业务一起伸缩。
