中国企业的国际化出海，已经在磕磕绊绊中，走过两个不同的阶段。
最初是以华为、海尔和联想为代表的科技制造企业出海，作为中国最早迈向国际化的这一批中国科技企业，如今都已经成长为全球化的品牌。
其后随着中国互联网经济的爆发，中国的互联网企业崛起，逐渐向海外进军。比如中国的游戏、互联网服务、手机等企业都开始了海外征途，这个阶段出海的本质是中国互联网商业模式的出海。相比于早期的制造业出差，今时今日的中国企业出海，必然伴随着本地化的云服务，来满足全球一体化运营的诉求。
在这些出海企业眼中，谁是全球公有云的代表？Azure、AWS，还是谷歌云？
公有云毕竟是一个典型的技术驱动，当大企业开启上云路径之后，全局化，甚至全球化的技术服务能力，乃至跨越国境、跨越洲境的稳定服务能力正在逐渐成为关键。
在一项针对Azure、AWS和谷歌云的三云测试中，通过分布在亚太、北美和欧洲的跨境测试。结果令人乍舌，Azure表现出来的性能明显优于其他两家云服务商。
如果以技术能力作为第一衡量指标，Azure绝对是中国企业出海的第一选择。我们可以一起看看这次测试的全过程。注：本文篇幅有限仅选取互联网出海最关心的网络延迟及带宽来做对比评测，特此说明。
1. 网络延迟测试
网络延迟（Network Latency）是非常重要的网络性能指标之一，也是体现数据中心网络性能的重要参数。对于一些对延迟非常敏感的关键业务比如交易系统、在线游戏、视频等，资源的使用者通常希望其网络延迟越低越好。
网络延迟是指报文在传输介质中传输所用的时间，即从报文开始进入网络到它开始离开网络之间的时间。网络延迟的大小，一般是通过端到端的流量转发进行测试。常用网络延时最常用的工具就是ping了，它几乎忽略了服务器的性能对延时的影响，测试的结果非常具有参考意义。工作时 ping 向目标主机发送一个 IMCP Echo 请求的数据包，并等待接收 Echo 响应数据包，通过响应时间和成功响应的次数来估算丢包率和网络时延。由于网络的复杂性、网络流量的动态变化和网络路由的动态选择，网络延迟随时都在不停的变化。网络延迟和网络延迟的抖动越小，那么网络的性能就越好。
1.1 地区选定
本次测试在Azure、AWS和谷歌云三家云厂商相同地区、配置相似的虚拟机上进行ping连通测试，对比三家云厂商的网络延迟性能。虚拟机地区选择的详细情况如表Tab. 1.1所示，选择地区分布在亚太、北美和欧洲，横跨全球。
Tab.1.1 虚拟机地区选择
云厂商 |
Region |
||
Azure |
Singapore |
US East2 |
UK South |
AWS |
Singapore |
Northern Virginia |
London |
GCP |
Singapore |
us-east4(Northern Virginia) |
europe-west2 (London) |
1.2 测试方法
使用系统自带的ping工具。三个区域，两两相互分别ping对方的publicIP和privateIP 30分钟（24小时），统计latency的min, avg和max值，并作时序图观测网络抖动情况。
1.3 测试结果
SG: Singapore
US: US East2, Northern Virginia
UK: London, europe-west2(London)
测试结果统计如下：
Tab.1.2 SG ping US & US ping SG
Cloud |
Azure |
AWS |
GCP |
||||||
Region |
Min |
Avg |
Max |
Min |
Avg |
Max |
Min |
Avg |
Max |
SG -> US |
225.889 |
227.997 |
257.843 |
229.722 |
230.16 |
231.326 |
206.338 |
206.522 |
210.842 |
US -> SG |
225.902 |
228.034 |
261.123 |
229.707 |
230.319 |
231.204 |
206.377 |
206.517 |
209.73 |
Tab1.2为Singapore和US的互ping测试结果。此项Azure表现略优于AWS，平均延迟比AWS少了3ms左右，GCP表现较好，延迟平均在206ms左右。
Tab.1.3 SG ping UK & UK ping SG
Cloud |
Azure |
AWS |
GCP |
||||||
Region |
Min |
Avg |
Max |
Min |
Avg |
Max |
Min |
Avg |
Max |
SG -> UK |
179.668 |
180.383 |
207.208 |
165.969 |
171.369 |
175.444 |
279.854 |
283.64 |
287.072 |
UK -> SG |
179.713 |
180.336 |
214.591 |
165.27 |
170.831 |
173.241 |
279.396 |
283.224 |
288.123 |
Tab. 1.3 为新加坡和伦敦地区的互ping测试结果。相比新加坡到美国，新加坡与伦敦距离稍近，Azure和AWS的延迟都比从新加坡ping美国少了40ms左右。AWS和Azure总体表现较好，比GCP少了100ms左右；谷歌云延迟平均比它从新加坡到美国反而多了80ms左右。
Tab 1.4US ping UK & UK ping US
Cloud |
Azure |
AWS |
GCP |
||||||
Region |
Min |
Avg |
Max |
Min |
Avg |
Max |
Min |
Avg |
Max |
US -> UK |
78.646 |
79.625 |
113.214 |
75.44 |
75.555 |
85.141 |
74.355 |
74.565 |
79.63 |
UK -> US |
78.633 |
79.476 |
82.133 |
75.434 |
75.535 |
80.516 |
74.442 |
74.606 |
79.402 |
Tab. 1.4 为美国弗吉尼亚和伦敦地区的互ping测试结果。由于距离更近，三个云厂商的延迟都大大降低，平均降低了100ms左右。
总的来说，Azure网络延迟表现稳健，与AWS相比都在±3~4ms左右，都与距离成正相关；而GCD美国到英国的延迟反而很大。
Tab. 1.5为Timeslot，能直观地体现延迟抖动情况：
Tab.1.5. Time Slot
新加坡与US互ping，Azure抖动相比之下稍微多一些，但总体保持稳定，而AWS有明显的阶跃；AWS和谷歌云全都向高延迟抖动，而Azure会向低延时抖动。
新加坡与伦敦的互ping，Azure总体表现最为平稳，而AWS在长时间段抖动很厉害，GCP抖也较频繁。
US与UK的互ping三家云厂商都表现得不错，抖动均比较小，但AWS和GCP会在某一时刻突然有很大的抖动，而Azure总体表现平稳，不会大起大落。
2. 网络带宽测试
网络带宽是衡量两个网络节点之间通信性能的重要的指标之一。在评估云服务的时候，要充分考虑网络带宽对所承载的网路服务的影响。若已经部署的网络服务出现了故障，有时候可以考虑从网络实时带宽的角度来进行故障排查。
2.1 地区选定
本次测试在Azure、AWS和谷歌云三家云厂商相同地区、配置相似的虚拟机上进行带宽测试，对比三家云厂商的带宽情况。虚拟机地区选择的详细情况如表Tab. 2.1所示，选择地区分布在亚太、北美和欧洲，横跨全球。
Tab.2.1 虚拟机地区选择
云厂商 |
Region |
||
Azure |
Singapore |
US East2 |
UK South |
AWS |
Singapore |
Northern Virginia |
London |
GCP |
Singapore |
us-east4(Northern Virginia) |
europe-west2 (London) |
2.2 测试方法
2.2.1 SCP测试
SCP（Secure Copy）协议用来实现“本地机器与远端机器之间”或者“远端机器和远端机器之间”文件传输协议。SCP协议基于SSH协议，通过建立SSH连接隧道作为数据传输通道，对数据传输进行加密，从而保证数据传输的安全性。
本测试在跨区域的实例之间通过scp协议传输1G、2G和5G文件，每种类型的文件传输5次，并写入log文件进行记录。具体给出了以下测试结果：
·每次测试的平均传输速率（MB/s）
·传输1G/2G/5G文件的平均完成时间（*m*s即*分*秒）
·每个云厂商的SCP平均传输速率（MB/s）
◆UK & US
三个云厂商美国数据中心所在城市为：Azure
上表给出了美国与英国两个区域之间虚拟机实例SCP传输数据带宽测试结果：
·三家云厂商在美国与英国两个区域之间的数据传输较为稳定，其中Azure与GCP表现较好，AWS传输速率相对落后；
·从传输速率上看，Azure平均数据传输速率为24.43MB/s，与GCP的25.40MB/s相差不大，AWS的数据传输速率为19.36MB/s；
·从传输时间上看，1G数据SCP传输时间Azure与GCP均在40s左右，领先AWS约10s；2G数据SCP传输时间Azure与GCP均在1m20s左右，领先AWS约20s；5G数据SCP传输时间Azure与GCP均在3m25s左右，领先AWS约1min；
随着数据量的增大，数据传输速率带来的影响愈加明显。
◆SG & UK
上表给出了英国与新加坡两个区域之间虚拟机实例SCP传输数据带宽测试结果：
·三家云厂商在英国与新加坡两个区域之间的数据传输较为稳定，其中Azure传输速率领先AWS和GCP；GCP没有变现出在美国与英国两个区域间优秀表现，在英国与新加坡两个区域之间数据传输速率明显落后于Azure和AWS；
·从传输时间上看，1G数据文件，Azure传输完成时间领先AWS约10s，领先GCP约50s；
·2G数据文件，Azure传输完成时间领先AWS约37s，领先GCP约1m50s；5G数据文件，Azure传输完成时间领先AWS约1m10s，领先GCP约4m16s；
◆US & SG
上表给出了新加坡与美国两个区域之间虚拟机实例SCP传输数据带宽测试结果：
·三家云厂商在新加坡与美国两个区域之间的数据传输较为稳定，GCP的数据传输速率在这两个区域之间略好于Azure，但差别不大。AWS的数据传输速率明显落后于Azure和GCP；
·从数据传输完成时间来看，1G数据Azure与GCP传输时间均在2min以内，AWS传输时间达到2m37s；2G数据Azure与GCP传输时间均在4min以内，AWS传输时间达到5m24s；5G数据Azure与GCP传输时间均在10m以内，AWS传输时间达到13m21s；
总结
图：各区域间SCP数据传输速率三云对比
·从总体上看，Azure在不同区域之间的数据传输速率都处于第一梯队中，传输稳定且速率较快，充分说明Azure骨干网络的稳定性，为微软各类服务提供数据传输保障；
· AWS的数据传输速率总体表现不佳，甚至出现明显落后与Azure与GCP的情况，骨干网的数据传输性能不够理想；
·GCP的数据传输在美国与新加坡和美国与英国之间表现较好，但在英国与新加坡之间出现明显落后于Azure和AWS的情况，说明GCP骨干网络性能不够稳定，个别区域的网络传输速率较慢。
2.2.2 HTTP测试
HTTP协议全称是Hyper Text Transfer Protocol（超文本传输协议），该协议工作于客户端-服务器架构，浏览器作为HTTP客户端通过URL向HTTP服务器端（即Web服务器）发送请求，Web服务器根据接收到的请求，向客户端发送响应信息。HTTP协议是无连接，无状态的协议，每次连接只处理一个请求，服务器处理完客户请求并收到客户应答后即断开连接，且每次连接处理的事务状态不会进行记忆，因此它的应答比较快。不像SCP协议需要维护SSH协议加密通道，HTTP协议没有这一层开销因此更能反映网络的数据传输速率。
由于HTTP是C-S架构的协议，因此在进行测试的时候先令一个区域的虚拟机实例充当HTTP服务器，在另一个区域上的虚拟机实例作为客户端，通过wget命令分别请求1G、2G、5G大小的数据文件，每种大小的数据文件测试五次，并写入log文件进行记录。
虚拟机实例充当HTTP服务器的方法：使用Python中SimpleHTTPServer模块，默认端口8000。
本测试在跨Region的实例之间通过scp协议传输1G、2G和5G文件，每种类型的文件传输5次，并写入log文件进行记录。具体测试结果如下：
◆UK & US
·测试中UK作为Server端，US作为Client端，分别传输1G、2G、5G数据
·从HTTP数据传输速率来看，Azure数据传输速率最优，GCP其次，二者均达到30MB/s以上，但AWS的数据传输速率较低，仅为19.51MB/s
·需要说明的是，GCP在进行5G文件的HTTP测试时，速率出现降至1MB/s以下的情况，且这种状态持续至该篇文档编辑时，因此缺少测试结果，以“*”号表示。这种异常状态，不计入最终测试结果，因此对于GCP的测试仅取正常状态下的测试结果。
◆SG & UK
·测试中SG作为Server端，UK作为Client端，分别传输1G、2G、5G数据
·从HTTP数据传输速率来看，Azure数据传输速率明显高于GCP和AWS，超AWS的数据传输速率接近一倍
◆US & SG
·测试中US作为Server端，SG作为Client端，分别传输1G、2G、5G数据
·从HTTP数据传输速率来看，GCP在美国和新加坡这两个区域的HTTP数据传输速率比较高，与Azure数据传输速率相差不大，AWS的HTTP数据传输速率仍明显落后
总结
图：各区域间HTTP数据传输速率三云对比
·从整体上看，Azure的HTTP数据传输速率明显领先于AWS和GCP的骨干网络性能；
·GCP的HTTP数据传输速率在部分区域间性能表现较好，但会出现较严重的不稳定情况；
·AWS的HTTP数据传输速率明显低于Azure甚至GCP，因此会对用户的使用体验带来一定程度的影响。
2.2.3 iPerf工具
网络带宽测试的工具有很多，测试方法也多种多样。针对 Azure 的虚拟机和云服务，推荐使用 iPerf 来进行网络带宽测试。iPerf 是专业的网络测试工具，它基于 TCP/IP 和 UDP/IP 协议，用以测量两个网络节点之间 TCP 和 UDP 端口的网络带宽，还能提供网络延迟、丢包率等统计信息。
iPerf 常用的版本有 iPerf2 和 iPerf3。 iPerf3 在 iPerf2 的基础上新增了一些功能，例如发送方/接收方角色互换，以 JSON 格式输出结果，零拷贝方式传输数据等等。也去掉了 iPerf2 中所支持少许功能，例如双向测试，以逗号为分隔符输出结果等。iPerf3 和 iPerf2 所执行的命令名字也不一样，iPerf3 为 iperf3，iPerf2 为 iperf。可以根据实际需要来选择安装的版本。下文中的测试都以 iPerf3 为例。
iPerf 在工作时，测试的两端一方作为 Server，另一方为 Client。程序启动的命令相同，通过不同的参数来区别以哪种工作方式运行。通常情况下先启动 Server 端，使 iPerf 监听在某个固定端口。然后在 Client 端执行相应的命令开始测试。
以下为测试结果，进行2分钟iperf3测试：
Transfer
·与2.2.2的测试结果类似，SG & US iPerf测试中， GCP在美国↔新加坡这两个区域的Bandwidth最高，与Azure相差不大，但AWS的Bandwidth明显落后，几乎只有Azure核GCP bandwidth的一半；在右边2分钟传输的流量大小可以看出，GCP能在2分钟内传1.6 GB，Azure1.5GB，而AWS只能传0.8GB
· SG↔UK区域，Azure数据带宽明显高于GCP和AWS，达到了130Mb/s，是AWS的1.76倍，是GCP的1.5倍，这也从另一个角度解释了2.2.2中Azure传输速率最高，且远远超过AWS和GCP的原因
·US到UK区域，GCP的Bandwidth与Azure差距不大，但都远远高于AWS
综上所述，在带宽测试中，大部分情况下Azure的Bandwidth都基本优于GCP且大大优于AWS，但不排除虚拟机选型的影响—— 即使我们都选用了2核8GB内存的虚机，不同型号的虚机自身Bandwith限制也有不同。后续应在保持vCPU:Memory比的同时多测几组机型加以改进测试。
看到这里的观众属于走心挂，公有云的选择延迟和带宽是一方面，和业务的紧密性，甚至于公有云还会影响到企业出海是否合规....我们已经说了那么多，更多想知道的可以去现场找微软的技术咖——微软将从9月开始，陆续举办一系列针对中国出海企业的线下及线上“企业出海峰会”。
届时你将会：
扫描二维码或阅读原文，
免费获取全行业出海流程规划白皮书，
抢占企业出海峰会名额。
点击“阅读原文”，领200美金微软Microsoft Azure国际版试用账号！