业务涨到一定规模，很多中小团队都会碰到同一个情况：原来的服务器开始扛不住，要么加机器，要么升配置。这时候阿里云拓机基本是绕不开的一步。简单说，拓机就是在现有架构上补充计算资源，再把新机器稳定接进业务里。步骤看起来不多，但选型、网络、部署里任何一环走偏，上线都会拖慢。下面用一个案例把关键步骤讲清楚。
拓机前先想清楚三件事
动手买机器之前，先把问题问明白。第一，瓶颈到底在哪？是CPU、内存、磁盘IO还是带宽？很多团队一看到响应变慢就直接加机器，结果发现拖慢的是数据库慢查询，新机器加了也没用。第二，未来三到六个月的流量大概是什么量级。买太小，过不了多久又要返工；买太大，闲置就是白花钱。第三，新机器承担什么角色。无状态的Web节点和需要持久化数据的服务，选型和运维方式完全不同，别混为一谈。
案例：在线教育团队的扩容过程
一支在线教育团队在寒暑假招生期间，课程页面访问量在短时间内涨了好几倍，原来的两台应用服务器频繁超时。团队第一反应是升配，但排查后发现问题不在机器本身：静态资源和接口请求挤在同一台机器上，高峰期互相抢资源。
所以他们没有直接升配，而是按下面三步拓机：
- 新增两台云服务器专门处理接口请求，原来的机器留给后台管理和定时任务，两类负载不再互相干扰。
- 静态资源迁移到对象存储，再通过CDN分发，源站只处理真正需要计算的请求。
- 把新节点挂到负载均衡后端，逐台灰度切流。每切一台，先看错误率和响应时间，稳定后再全量放开。
整个过程不到一个工作日，高峰期的超时报错明显少了。这件事的关键是先找到瓶颈，再决定把新资源加在哪里。
阿里云拓机的标准操作流程
从控制台操作的角度，拓机大致包括下面几个环节：
- 选ECS实例时，综合看实例规格、地域和付费方式。优先和现有机器放在同一可用区，内网延迟更低，服务之间的调用也更稳。
- 配置安全组，只开放业务必需的端口。管理端口（比如SSH、远程桌面）建议限制来源IP，不要对全网开放。
- 挂载数据盘并规划目录，上线前用简单的读写测试确认磁盘性能够用，别等高峰期才发现IO跟不上。
- 用镜像或自动化脚本统一环境，保证新旧节点的运行版本、依赖和配置一致。
- 把新节点加入SLB负载均衡，并配置健康检查。健康检查没配，故障节点会继续接收流量，排查起来很被动。
常见坑点
第一个坑是新旧机器环境不一致。手动部署最容易出现这种情况，结果是”只在一台机器上能跑”。用镜像或Ansible这类工具固化配置，能省掉很多半夜排错的时间。
第二个坑是安全组配得太宽，把数据库端口暴露到公网。这是高风险操作，拓机完成后要专门检查一遍端口和来源IP范围。
第三个坑是忘了健康检查，或者检查路径只测了首页，实际接口已经挂了，负载均衡还在往上派请求。健康检查最好访问一个能反映真实服务状态的接口。
上线之后怎么验收
节点上线不等于拓机结束。建议至少观察一个完整的业务周期，重点看CPU负载、响应时间和错误率。如果某台机器长期空闲，可以考虑缩容，或者改成按量付费，把成本降下来。
另外，把这次拓机的架构变更写进文档，包括新增了哪些节点、端口和负载均衡规则是怎么配的。下次扩容时，有现成的记录，比临时翻控制台快得多。
拓机本身并不复杂，难的是判断瓶颈在哪。先诊断，再动手，配合标准化部署和灰度切流，扩容才能既稳又省。
