在将线下服务器迁移上云之后，线下局域网中的客户端如何访问云上VPC中的服务器成为一个突出问题，这种情况就像一个人的灵魂已经飞升，但肉体尚在在凡尘。为此我在前几期的文章中给出了几种解决的思路：

• 利用钉钉企业应用网关将应用移化后上云

  • 利用无影云桌面将客户端和服务器一起迁移上云

这两种解决方案都有一些“一人得道鸡犬升天的感觉”，都需要对应用的架构或者运维体系进行一些大刀阔斧的改变，有没有一种更兼顾传统IT架构的解决方案呢？今 天我就给大家分享一个这样的方案：

为了解决跨运营商相互访问的问题，很多传统IT客户都会购买链路负载均衡设备，就是通过该设备实现多条运营商线路的就近访问和负载均衡。利用链路负载均衡和阿里云的SAG我们就能实现这样一个传统+现代的上云解决方案。有关SAG智能接入网关我们在之前的文章中介绍过多次了，这里就不在赘述了。

这里的关键是有两个以上的SAG以及链路负载均衡设备，我们知道SAG相对于专线来说可靠性略差，通过购买多个SAG进行负载均衡及故障切换可以在很大程度上弥补这一劣势。而在规划SAG的带宽时可以将规划的带宽一分为二，平均分配到两个SAG上，再加上保有量巨大的链路负载均衡设备，这样很多时候增加的成本仅仅是一个额外的SAG设备。

具体的解决方案架构如下：

• 这里假设云上的VPC的网段是172.16.0.0/16、云下局域网的网段是172.17.0.0/16，要实现云下局域网的客户端流畅可靠的访问云上VPC中的服务器。
• 购买两个SAG，SAG A的内网设置为192.168.1.0/24，SAG B的内网设置为192.168.2.0/24。这样在阿里云的角度来看有两个独立的分支站点要上阿里云。
• 利用链路负载均衡将这两个独立的分支站点进行合并及负载均衡，由于进行了SNAT地址转换，云上VPC中的服务器看到的依然是从两个独立的分支站点发送来的访问请求。
• 当其中一条SAG的线路发生中断时，链路负载均衡的健康检查机制将立即发现并自动将所有的访问请求切换奥剩下的一条SAG线路，当故障链路恢复后，链路负载均衡将及时切换成负载均衡状态，保证带宽资源的充分利用。

这是一个线下客户端和设备主动访问云上服务的出向负载均衡方案。假如云上服务器反过来要访问线下的服务器，可以将链路负载均衡按照入向负载均衡的模式配置为多个“站点”，并借助于HAProxy这一类的第三方软件将请求负载均衡到从属于不同“站点”的服务入口地址上。

其实这里的SAG也可以替换成专线或者IPSec VPN通过链路负载均衡这些具体的上云方式对于线下客户端来说都是透明的。