背景

一方面，作为阿里云老用户，默认使用的经典网络，曾经简便易用，入门简单；然而，时过境迁，虽然规模的不断扩大，产品的不断丰富，经典网络也开始暴露各种如安全性、配置复杂甚至阿里云地址池不够用等等问题。阿里云也在2016年6月启动了专用网络策略，没有经典网络ECS实例的用户，只能购买专有网络ECS实例，各项新功能和各种新产品也不再支持经典网络，所以必须迁移到专用网络。
另一方面，公司业务已运行多年，系统众多，主要使用微服务架构，但是服务规划和治理水平没有跟上，服务间调用关系复杂，系统间相互依赖也不少；同时系统和服务数量庞大，无法直接整体迁移VPC。
所以，我们独辟蹊径，不从业务系统级别，而是从云产品级别逐步迁移改造，使所有相关依赖都可以在两个网络环境中访问。

SLB的迁移

我们的业务系统间甚至服务间不仅通过服务注册发现来相互调用，也会通过SLB来相互调用。曾经，因为SLB无法平滑过渡，我们的VPC迁移计划搁置了很久。因为整个业务系统没法整体迁移，调用关系又很复杂，所以阿里云提供的迁移工具SLB混挂，在我们的场景下没法完成预期目标。
1.当A系统在经典网络，B系统在VPC时，如果是A访问B，那么给B系统挂载个经典网络的SLB，确实可以完成目标；但是如果还有个C系统在VPC，也要访问B系统，那么这个B系统的经典网络的SLB，C系统就访问不到了。所以这样做不行。
2.那么，反过来呢？也就是先给B系统挂载个VPC的SLB，然后让C和A系统来访问呢？C系统当然可以直接访问了，然而A系统是经典网络的，同样没法直接访问B系统在VPC的SLB。
3.好吧。既然，不管是挂载VPC的SLB还是挂载经典网络的SLB都不行，那么挂载公网的总行了吧？确实行。不过，本来是内网的SLB，现在换成了公网的SLB，虽然是过渡阶段，但是安全风险还是很大。如果要用这个方案，那么必须给每个SLB的每个监听加上访问控制。由于我们的SLB和监听端口数量非常大，ECS也经常新购和释放，人肉来做效率很低，也很容易出错，所以我们决定开发个自动处理SLB访问控制的程序来做这个事情。甚至，这个程序我们都做好了。
4.然而，就在我们测试ECS Classlink时，我们发现，当经典网络的ECS接入对应VPC的classlink后，这个ECS即可访问VPC内的所有产品，包括SLB。不过，这个SLB要在classlink允许访问的交换机网段上。
所以，迁移SLB的方案就变成了这样：先把所有相关的ECS都开启classlink，然后把所有的内网SLB都切换到VPC里。这样，SLB的迁移就完成了。当然，重新配置SLB以及其监听，重新发布部署服务挂载到VPC SLB上，把上游调用方的访问地址切换到新的SLB上，然后再下掉老的SLB和服务都是必须的，而且要很小心去做。

ECS的迁移

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



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

其他产品

除了SLB和ECS，阿里云的其他产品，如RDS、MongoDB、Redis、OSS、MNS/MQ等，都提供了混访模式，也就是在过渡期间，给每个实例都分配一个VPC地址，同时继续保留原来的经典网络地址，这样，不管使用方所在的网络是经典网络还是VPC网络，都可以访问到。
当全部迁移VPC完成后，经典网络的地址就可以释放掉，所有产品就完全变成了VPC网络。这里要注意的是，当这些产品切换到VPC后，虽然经典网络地址还继续保留，但是是有保留时间限制的，需要在一段时间内迁移完毕或者经常续期。另外，一旦切换到VPC后，默认显示的各种信息就都是VPC网络的，要使用经典网络地址时需要特别留心注意不要搞错地址。

总结

以上就是我们从经典网络迁移到专有网络VPC时将阿里云产品逐个切换到VPC网络的方法，其实都是阿里云官方方式，classlink、混挂、混访。通过这种方式，我们基本解除了系统间的依赖，不管先迁移哪个系统，都没有太大的影响。不过，在具体场景下，要完全做到平滑，还是需要特别注意，要多做测试，同时也还是要注意操作步骤和相互依赖。