阿里云各产品从经典网络迁移到专有网络VPC的技术要注意什么-核心信息和使用场景并不只看表面做法，关键还要理解相关条件、限制和后续影响。

背景容易忽略的点

判断阿里云各产品从经典网络迁是否好用，关键不在功能堆得多，而在背景、SLB的迁移、ECS的迁移能不能解决真实需求。下面从实际使用角度重新梳理。

换到实际使用里，另一方面，公司业务已运行多年，系统众多，主要使用微服务架构，但是服务规划和治理水平没有跟上，服务间调用关系复杂，系统间相互依赖也不少；放在具体场景中，同时系统和服务数量庞大，无法直接整体迁移VPC。

所以，我们独辟蹊径，不从业务系统级别，而是从云产品级别逐步迁移改造，使所有对应依赖都可以在两个网络环境中访问。

SLB的迁移容易忽略的点

换到实际使用里，我们的业务系统间甚至服务间不仅通过服务注册发现来相互调用，也会通过SLB来相互调用。因为整个业务系统没法整体迁移，调用关系又很复杂，所以阿里云提供的迁移工具SLB混挂，在我们的场景下没法完成预期目标。放在具体场景中，曾经，因为SLB无法平滑过渡，我们的VPC迁移计划搁置了很久。

更直接地说，所以这样做不行。1.当A系统在经典网络，B系统在VPC时，如果是A访问B，那么给B系统挂载个经典网络的SLB，确实可以完成目标；从操作角度看，但是如果还有个C系统在VPC，也要访问B系统，那么这个B系统的经典网络的SLB，C系统就访问不到了。

从操作角度看，C系统当然可以直接访问了，然而A系统是经典网络的，同样没法直接访问B系统在VPC的SLB。需要先分清的是，也就是先给B系统挂载个VPC的SLB，然后让C和A系统来访问呢？2.那么，反过来呢？

更直接地说，确实行。不过，本来是内网的SLB，现在换成了公网的SLB，虽然是过渡阶段，但是安全风险还是很大。如果要用这个方案，那么必须给每个SLB的每个监听加上访问控制。由于我们的SLB和监听端口数量非常大，ECS也经常新购和释放，人肉来做效率很低，也很容易出错，所以我们决定开发个自动处理SLB访问控制的程序来做这个事情。换到实际使用里，甚至，这个程序我们都做好了。3.好吧。既然，不管是挂载VPC的SLB还是挂载经典网络的SLB都不行，那么挂载公网的总行了吧？

更直接地说，4.然而，就在我们测试ECS Classlink时，我们发现，当经典网络的ECS接入对应VPC的classlink后，这个ECS就能访问VPC内的所有产品，包括SLB。更直接地说，不过，这个SLB要在classlink允许访问的交换机网段上。

更直接地说，所以，迁移SLB的方案就变成了这样：先把所有对应的ECS都开启classlink，然后把所有的内网SLB都切换到VPC里。当然，重新配置SLB以及其监听，重新发布部署服务挂载到VPC SLB上，把上游调用方的访问地址切换到新的SLB上，然后再下掉老的SLB和服务都是必须的，而且要很小心去做。更直接地说，这样，SLB的迁移就完成了。

ECS的迁移容易忽略的点

更直接地说，这种迁移方式有个好处，公网IP会被保留下来，在一些特殊场景比如公网IP被外部依赖的时候会非常有用。从操作角度看，不过这种操作ECS需要重启，而且只能主账号操作，我们只有在个别情况下才使用。对于ECS，阿里云提供了直接迁移的方法，可以在实例的【更多】-【网络和安全组】里选择【预约迁移至专有网络】然后按照步骤就可以完成迁移。

更直接地说，这个也是迁移VPC第一步要完成的。ECS我们一般不使用直接迁移的方式，而是在VPC内新购买机器，重新部署和搭建服务，并开放给经典网络和VPC网络中的所有调用方使用。从操作角度看，不过，虽然不做迁移，但是必须要跟VPC能互访，所以所有ECS都开启classlink是必须的。

其他产品要先看什么

放在具体场景中，除了SLB和ECS阿里云的其他产品如RDS、MongoDB、Redis、OSS、MNS/MQ等都提供了混访模式也就是在过渡期间换到实际使用里，给每个实例都分配一个VPC地址同时继续保留原来的经典网络地址这样不管使用方所在的网络是经典网络还是VPC网络都可以访问到。

更直接地说，当全部迁移VPC完成后，经典网络的地址就可以释放掉，所有产品就完全变成了VPC网络。更直接地说，这里要注意的是，当这些产品切换到VPC后，虽然经典网络地址还继续保留，但是是有保留时间限制的，需要在一段时间内迁移完毕或者经常续期。另外，一旦切换到VPC后，默认显示的各种信息就都是VPC网络的，要使用经典网络地址时需要特别留心注意不要搞错地址。

总结