随笔 - 10  文章 - 0 评论 - 0 trackbacks - 0

最近遇上客户有这么个需求,手机用户在国内发起一个http请求,通过国内的Web前端访问国外的数据平台获取数据,然后按获得数据,Web前端生成页面返回给手机用户。看上去很简单的需求,但是由于某些不可描述的原因,整个应用从发起请求到最终返回页面,总共花了几十秒时间,这玩意是个用户就不会等。所以我们的客户怒了,要求应用必须在5秒内返回结果。客户第一个想到的就是拉根专线,不过一打听拉根去海外的专线价格,客户就来找微软了,总结下客户的要求大概是这样的:“不管怎么说,我们国内的应用部署在Azure上了,你们微软帮我想办法搞定这个事,而且价钱要控制住。”。

其实这个事,如果客户国外的数据平台也是部署在Azure上,这就是个很标准的解决方案,我们可以在Azure China和Azure HK之间建立一个VPN通道,然后利用Azure全球的数据中心之间的骨干网就可以直接访问了。我的同事已经写了一篇很详细的文章来解释怎么实现。大家有兴趣可以参考这篇文章:

Azure 多站点访问的实践

 

但是,这次的客户在国外的数据平台部署在了其它的数据中心里。上述方案不能直接使用,。比较幸运的是我们在Azure的应用市场里找到了一个解决方案:

https://market.azure.cn/Vhd/Show?vhdId=12145&version=14311

不管怎么说,这个方案看上去还是很不错的样子。接下来的事大家应该都知道了:客户要做测试。长话短说,虽然测试过程并非一马平川,但是经过大家的努力,最终测试结果还是获得了客户的认可:

 

 

总的来说,就是95%的请求时间少于1.9秒,99%的请求时间少于2.9秒。68000次测试请求中只有2次失败。效果很好,客户很满意,可以签合同了。

 

如果用Azure提供的解决方案和我们的友商同时进行的测试结果来比较,我们可以看到Azure的解决方案更稳定,更别说双方报价还要差了那么几倍。所以客户的最终选择也是理所当然的了。

 

友商测试结果

 

Azure测试结果

 

 

 大家如果看过了上面的Azure镜像市场的链接,那么应该知道Azure所提供的解决方案是基于CloudWAN的。在这次的测试中,最终实现的拓扑结构如下图所示:

 

在客户部署在Azure东区的应用前端,通过VPN网关与部署在Azure北区的CloudWAN POP点建立IPSEC隧道,然后利用CloudWAN的全球网络将流量转发到客户的海外数据平台。这样就轻而易举的打通了国内应用平台到海外的通道。当然按照相关法规,备案什么的都不能少。

 

当然,作为工程师,我们并没有就此满足,Azure的多站点解决方案是否可以经过一些变化满足客户需求,是否也可以达到类似的效果。其实我们已经搭了一个完全基于Azure VPN的解决方案,在Azure中国和Azure香港间建立VPN隧道,并以此为跳板访问客户的数据平台,不过由于客户海外同事去度假了,所以还没有拿到最终的测试数据。希望下次有机会给大家更新这方面的结果。

posted on 2017-09-04 14:56 johntoo 阅读(...) 评论(...) 编辑 收藏