企业上云时，虚拟机通常是最先接触的基础资源，网站、应用和数据库大多先落在它上面。选得合适，后面的运维会轻松很多；选得不对，要么高峰期卡住，要么每个月白白多付钱。阿里云的云服务器ECS（Elastic Compute Service）在国内用的人不少，下面结合选型思路、部署要点和一个迁移案例，把阿里云虚拟机怎么用讲清楚。
先搞清楚一台实例由哪些部分组成
说一台虚拟机，其实是几样东西配合在一起。创建时每一项都要过一遍，因为有些一旦定下来，改起来很麻烦。
- 实例规格决定CPU、内存和网络能力。通用型适合大多数Web站点和中小应用，计算型偏向高并发计算，内存型更适合缓存和大型数据库。
- 镜像是操作系统加预装环境。想快速复制一套已经调好的环境，就用自定义镜像，不必每台都从头配。
- 系统盘放操作系统，数据盘放业务数据。业务数据尽量放在数据盘，后面扩容、做快照、迁移都省事。
- 公网带宽决定对外访问速度。按固定值还是按流量计费，主要看访问量是否稳定。
- 安全组相当于实例前面的一道虚拟防火墙，入站和出站规则都在这里控制。
选规格时，别一上来就选最高配
不少团队选型时直接买最高配，觉得这样稳妥。前期确实不容易出事，但长期看，大部分资源都在空转，钱花在闲置上。更务实的做法是先估算负载，跑一段时间，再根据监控数据调整。
判断时可以先问三个问题。业务是什么类型？静态站和API对CPU的要求不一样，数据库则更吃内存和磁盘I/O。峰值和平均值差多少？如果峰值是平时的几倍，按峰值配会浪费，按平均值配又会在高峰卡住，这时更适合用弹性伸缩兜底。计划用多久？长期稳定运行的服务适合包年包月，测试或波动大的任务用按量付费更灵活。
磁盘也要提前想。如果业务数据一开始就和系统盘混在一起，后期想单独扩容或迁移时会很被动。
部署和安全，最容易被忽略的几处
实例能开机只是开始，真正出问题往往出在部署细节上。下面几点都是常见的坑，建议创建后马上处理。
- 登录方式优先用SSH密钥对，并关闭密码登录。弱密码又暴露在公网上的服务器，很容易被暴力破解，常见后果是机器莫名被占满CPU。
- 安全组只开放业务需要的端口，比如Web服务开放80和443。22端口之类的管理端口，限制到固定的办公IP段，不要对所有地址敞开。
- 系统补丁要定期更新，重要数据配置定时快照。快照不等于完整备份，但出问题时能更快回到可用状态。
- 接入云监控并设置告警，重点关注CPU、内存、磁盘和带宽。阈值不必一开始就很精细，先能发现异常，再逐步收紧。
- 日常操作使用RAM子账号，不要一直用主账号干活。主账号权限大，一旦泄露，影响面也大。
一个迁移案例：从自建服务器到阿里云
某服装电商团队原本把网站放在一台自建物理服务器上。平时还能应付，但每逢晚间高峰就明显变慢，机房维护又带来过两次计划外停机。团队决定迁到阿里云虚拟机，顺便调整了架构。
规格怎么定
团队先翻看了过去三个月的访问日志。日常流量比较平稳，大促期间的并发量约为平时的五倍。最后选了两台通用型实例做应用服务器，分布在不同可用区，前面挂负载均衡；数据库单独用内存型实例，数据盘独立挂载。日常成本可控，峰值也有余量。
迁移怎么做
团队先在阿里云上搭出与原环境一致的镜像，再用自定义镜像创建第二台应用服务器，避免手工配置出现差异。数据迁移前在测试环境完整演练了两次，并记录每一步的耗时。正式切换时，停机窗口控制在十分钟以内。
上线后的变化
应用服务器配置了按CPU使用率触发的弹性伸缩规则，大促前还做了一轮压力测试。经过一个完整的促销周期，因负载导致的页面超时没有再出现，运维人员也不用每周处理好几次应急，能把时间更多放在功能迭代上。
这个案例里没有什么特别的技术，难得的是选型、部署、监控和弹性扩展连成了一条完整的流程。规模不大的团队照这个思路走，通常比一开始追求一步到位更省心。
小结
阿里云虚拟机本身上手不难，难的是前期规划。把负载想清楚，选对规格，守住安全边界，再配上监控和弹性伸缩，基础设施就能稳定运行，后面也方便按实际情况调整。文中的配置和价格请以阿里云官网最新信息为准，正式选型前最好用自己的业务跑一次测试。
