很多较早用阿里云的人都在控制台里见过“经典网络”这个选项。服务器建在哪个网络里，机器之间怎么走内网，为什么有些功能只能在某种网络里用，这些问题不弄清楚，后面扩容和迁移时很容易踩坑。下面先讲经典网络是什么，再用一个案例说明它带来的影响，最后列出迁移前要核对的事项。
经典网络是什么
经典网络是阿里云早期的网络形态。同一地域内的云服务器（ECS）共用一张由平台统一规划的网络，内网IP由阿里云分配。用户不能自定义网段，也无法划分子网。能自己管的主要是安全组，用来限定哪些IP或端口可以访问实例。
它的好处是省事。实例建好后，同地域的机器默认就能内网互通，不用先规划路由表和交换机。几台服务器、结构简单的业务，用经典网络基本够了。
和专有网络（VPC）相比，差在哪
专有网络是阿里云后来主推的网络形态。两者的主要差别有四点：
- 网段：经典网络的IP由平台分配，你定不了网段。专有网络可以自己指定CIDR网段，再切成多个交换机（子网）。
- 隔离：不同专有网络默认互不相通。经典网络内，同地域实例的网络边界比较粗，主要靠安全组拦截访问。
- 路由和网关：专有网络能配置路由表、NAT网关、VPN网关等。经典网络可用的网络功能少得多。
- 产品支持：部分新产品和新功能只在专有网络里提供，经典网络的新功能投入也在逐步减少。
阿里云已逐步收紧经典网络的新建策略，并推动存量资源迁移到专有网络。具体的开通限制和迁移时间节点，以阿里云官网最新公告为准。旧文章里的日期可能已经过期，不要直接照搬。
案例：一个小电商团队的网络困境
一家做服装零售的小团队（下称“A团队”）在2016年前后把网站部署在经典网络上。架构很简单：两台ECS做Web服务器，一台跑MySQL，一台做后台管理。所有实例位于同一地域，通过内网地址互访，安全组只开放80、443端口和SSH管理端口。这套环境稳定跑了好几年。
后来业务变大，A团队想增加一套独立的测试环境，还想通过专线连接公司办公网。问题随之出现：经典网络不能自定义网段，测试环境的IP段可能和办公网撞车，而专线接入需要的网络能力只在专有网络里提供。团队于是决定迁移。
迁移分三步走。第一步，在专有网络里规划网段，避开办公网正在使用的地址段，并按可用区切分交换机。第二步，用阿里云提供的经典网络迁移到专有网络工具，先在测试环境试跑，确认实例、安全组和数据库连接都正常。第三步，选在业务低峰期切换，原经典网络实例至少保留一周，出了问题可以回滚。
过程中碰到两个典型问题。第一，应用配置文件里写死了内网IP，IP一变，服务就连不上数据库。团队把地址改成域名，交给配置中心统一管理，问题才解决。第二，部分安全组规则依赖经典网络原来的默认放行，迁移后不重新梳理，个别后台接口就会访问失败。这两个问题各花了团队半天时间排查。
A团队的感受是，迁移的技术操作并不复杂，真正耗时间的是盘点依赖关系。哪些服务之间有内网调用，哪些IP写进了代码和配置，哪些安全组规则是历史遗留，这些都要在动手前列清楚。
迁移前的检查清单
- 列出所有经典网络实例，记下地域、内网IP、公网IP、安全组和挂载的云盘。后面每一步都以这份清单为依据，漏掉一台，切换时就可能少一个服务。
- 梳理实例之间的内网调用，包括数据库、缓存、消息队列和内部接口。最好画一张简图，标出谁调用谁。
- 在代码和配置里搜索内网IP，改成域名或配置中心管理。这一步同样要在测试环境验证。
- 规划专有网络网段时，同时考虑办公网、其他VPC和以后的扩展。网段一旦和其他网络重叠，后面调整会很麻烦。
- 先在测试环境完整演练一次迁移，检查业务功能和数据是否一致。
- 选好业务低峰窗口，准备回滚方案。原实例在验证通过前不要删除。
- 迁移完成后复核安全组规则，关闭不再需要的端口。
常见问题
经典网络实例还能继续用吗？
已经在运行的经典网络实例通常还能用，但新功能支持有限，平台对迁移的要求也可能逐步提高。长期运行的业务最好早点规划，别等到被要求了再仓促操作。
迁移会丢数据吗？
正规的迁移流程不会直接清空数据。但迁移前仍要对数据库和云盘做快照或备份。任何迁移都可能因配置出错导致服务中断，备份是最基本的保险。
经典网络和专有网络能互通吗？
可以通过ClassicLink等方式打通部分网络，但那是过渡方案，配置复杂，也有使用限制。如果要长期运行，直接迁移到专有网络更省心。
