作者所在公司前期没有专门的运维同学及运维网络方向思路的同学 所以早期选型选择经典类型的网络模型做默认网络方案。
阿里云网络早期方便、简单， 网络模型直接用了经典网络，导致网络扩展性比较差 ACL难控制。
（个人猜测认为 应该是早期阿里云早期产品pd 对网络需求不大 早期用户大部分群体也是单一的站长类用户 网络设计思路没有借鉴AWS 只需要机器搭建）
（由于编者水平有限,经验不足,文中难免有缺点与错误,希望广大读者批评指正。）

随着业务发展、网络控制能力太差，不同机器之前控制能力也越来越不方便。主要有下面4点
VPC 基于隧道技术，实现数据链路层的隔离，为每个租户提供一张独立、隔离的安全网络，不同专有网络之间网络完全隔离。
控制虚拟网络， 选择IP、配置路由表和网关等，从而可以轻松地实现内网的网络资源规划以及路由表的路径选择。
3、阿里云本身也是不推荐使用经典网络费用资源。
VPC 与经典网络的区别 。详见我写的阿里云网络情况
云上的IO性能当时比较差 结合资源和费用关系 已经想离线的计算数据操作迁移到IDC去处理。经典网络网络选择能力比较弱

1、合理规划网络网段。区分应用 业务情况 ，区分RDS redis mencache等第三方独立网络应用控制上网应用出口
2、业务不受损的情况下 完成迁移
3、合理的区分环境。 开发 测试 预发（环境） 线上 通过网络隔离资源的效果
4、一个应用 或者服务 多可用区 必要性
（真实案列中 因为早期作者考虑不是很全面 3、4 两条通过多次迁移改造成完成才成功）

四 、初步迁移方案及目标

牵涉近千台ECS 购买退费 预埋网络规划.（优点阿里云支持包年机器退回 缺点 换算比例很坑）
涉及200多人的研发团队配合及注意点.
涉及N个基础组件升级.
80-100（包括内部使用系统）多个应用按自己需求进行建议和网络控制 .
通过早期调研 确认阿里云以下产品需要解决
4、网络设施 VPC建立及业务的规划
5、外网开放的IP和端口
阿里云提供classlink方式。另外有一个大提前 我们的ECS可以接受重启发布。
混挂：混挂指一个负载均衡实例可以同时添加经典网络和 VPC 网络的 ECS 作为后端服务器接收监听转发的请求，且支持虚拟服务器组形式的混挂。公网和私网的负载均衡实例都可开通混挂。
经典网络类型的 ECS 不能访问 VPC 网络类型的私网 SLB。
VPC 网络类型的 ECS 不能访问经典网络类型的私网 SLB。
混访：指云产品可以同时接受经典网络和专有网络中的 ECS 访问，通常该类产品都提供两个访问域名，一个是经典网络访问域名，另外一个是专有网络访问域名。RDS、Redis、MongoDB 等产品都支持混访，其它还支持混访的云产品见阿里云。（）

因为涉及点 主要有以下几个方法。
VPC限制问题（对于大客户来讲 限制基本无 找技术TAM都可以 或者 钉钉群都可以无限扩展）
VPC 之间互联（如果有多个VPC）

运维同学跟研发同学确认：
（这一切都是没有CMDB的错 后续作者以这个需求模型为基础开发一个简意版本 但效果不佳 ）
与各业务小组确认好，哪些 ECS 需要直接对外提供访问，根据需求申请对应个数的 EIP。

迁移 RDS、Redis 至 VPC 网络类型并保留其经典网络地址
OSS 默认支持不同类型网络访问按项目迁移 ECS

公网 SLB 不用迁，私有经典网络 直接通过内部调整。
原先的ECS。新购买增加VPC网络的ECS，挂在SLB下面 然后部署应用 以权重不同观察业务 先分少量权重，后续观测无问题后，最后全部流量切至新的 VPC 网络 ECS 上，从 SLB 中移除经典网络 ECS，移除RDS、Redis、白名单，释放原经典 ECS 主机。

以研发同学重新发布 SLB切小量流量 观测 到达效果 。

五 、初步迁移大致流程

专有网络提供 ClassicLink 功能，使经典网络的 ECS 可以和 VPC 中的云资源通过私网互通。
经典网络和 VPC 互通与经典网络和经典网络互通的底层实现是一致 的，因此内网延迟不变，私网带宽限速不变。
宕机迁移、热迁移、停止、启动、重启、更换系统盘等操作不会改 变已建立的 ClassicLink 链接。

1、经典网络 <=> 专有网络:相互授权访问，推荐使用这种授权方式
2、经典网络 => 专有网络:授权经典网络 ECS 访问专有网络内的云资源.3、专有网络 => 经典网络:授权专有网络 ECS 访问经典网络 ECS第一种是目前配置 该配置是目前阿云里给出迁移ECS经典网络配置主流方式 之
该组网环境是目前部署的、结合混访混挂.
经典网络 <=> 专有网络:相互授权访问，推荐使用

以业务测切换流程、每个应用一个SLB，流程图为

3、业务代码沿用老的地址通过classiclink连接经典网络
4、测试成功、修改成VPC网络
5、将经典ECS 应用释放

随赠一件进行时 网络状态图

六 、哪些业务先迁移？
2、业务影响面比较少（如mysql 从库hadoop）
4、迁移人手充足 业务部门

七、迁移过程注意点风险点？
（classiclink前期可以解决、后期一一地址确认）
2、最老批机器经典网络不支持classiclink
（早期部分机型不支持classiclink 这个网络操作）
3、规划新的部署运维规范。解决新老配置位置不一
（我和该应用人员一起排查）
4、ECS机器网络未知问题
5、ECS 机器IP将会变化、但对我们业务不受影响
（影响点主要是：修改所有DNS内网解释）
6、本次迁移简单、主要还是量比较大、牵涉面十分广.

1、 OSS 开放搜索不受影响、代码层修改回原来经典网络iP
2、云数据库一但开启混访模式，classiclink到期 将不在支持经典网络环境（需要重新购买云数据库、迁移数据）
3、SLB 混访取消 切回挂载经典网络

技术上本次迁移还是十分简单、业务架构模型支持重启服务器 业务可以重新发布 阿里云的迁移的DTS 迁移方案较为成熟 数据库产品中只要支持混访模式比较轻松。难在量级比较大、各个系统牵涉面十分广 人与人之间沟通和协调配合，回顾是想沉淀些东西来 如果迁移过程中有更好的方案或者不懂的点 可以留言给我 一起进步探讨！！！