云端争霸：AWS、Azure、GCP、IBM 和阿里云测评比较
一年前，我们发布了第一份云性能报告，来解答这样一个关键问题：如何利用性能数据制定更明智的云决策？
云提供商竞相争夺市场主导地位，但云领域并非一成不变，无人稳坐江山。因此，我们有必要继续跟进，反复开展这项研究。我们仍希望回答这个关键问题：在云提供商竞相争夺主导地位的情况下，您如何靠云制胜？
大家早上好，我叫 Archana Kesavan，是第二期云性能基准测评的报告研究员，也是这份报告的主要作者。非常高兴代表 ThousandEyes 向大家讲解这份富有洞察力的报告。这份报告不偏向任何一家供应商。我们史无前例地以数据而非调查为依据，对五大云提供商的网络性能和连接架构进行了全面对比。
我们的研究始于 2018 年，当时我们发现各大云提供商的性能存在明显差距。我们希望改变那种情况，于是从网络性能和连接架构方面对 AWS、GCP 和 Microsoft Azure 进行了分析。
一年过去了，我们仍在继续这项研究。今年，我们主要从三个方面考察性能。首先是变化。云领域并非一成不变。我们可以观察逐年变化，更重要的是，找出引发这些变化的原因。
其次是覆盖范围。我们扩展了数据测量的范围，以涵盖对您最重要的观测点。在中国开展在线业务颇具挑战，因此我们非常关注这一地区。
我们还关注宽带互联网服务提供商 (ISP) 的性能，因为随着企业纷纷转向采用 SD-WAN 和混合 WAN，了解 ISP 与云的连接性能变得至关重要。AWS Global Accelerator 也在我们的关注范围之内，这是 AWS 去年推出的一项新服务，可提高 AWS 工作负载的性能和可用性。
最后，多云盛行，可供选择的云提供商越来越多。今年，我们将阿里云和 IBM Cloud 也纳入了研究范围，使得这项研究成为了迄今为止最广泛的云性能研究。
我们使用 ThousandEye 的数据基础设施引擎和分析引擎来收集这些数据。ThousandEye 的观测点遍布全球大约 200 座城市以及很多云提供商环境。
我们的 Agent 彼此持续通信，通过 TCP 流模拟用户流量。我们每隔 10 分钟定期测量网络性能，其中包括丢包、延迟和抖动指标。
由于两端都有观测点，因此我们可以双向观察性能。同时观察正向路径和逆向路径对于准确衡量网络性能非常关键，因为网络中不存在对称性。
我们还使用了路径可视化，从中深入洞察网络拓扑和连接架构。您会发现，路径可视化对我们要解答的许多问题至关重要。
今年的研究范围非常广泛，从最终用户测量开始，一直到多云连接，均包含在内。也就是说，进出云端以及云内部的一切活动都在我们的测量范围之内。
我想重点说一下最终用户测量。最终用户测量以及用户使用云服务的方式至关重要。从全球 98 个地点中，我们选择了所评估的五家云提供商均有涉足的 95 个地区进行监控。在测量宽带 ISP 性能时，我们也采取了类似的方法。我们测试了从美国六座城市到五家云提供商的北美托管中心的宽带连接情况。
这些连接关系着我们使用的服务的性能。我们知道，云应用基于微服务、高度分散，托管在云提供商的多个可用性区域或多个地区。因此，深入研究可用性区域间的性能、地区间的性能以及多云连接至关重要。
我们进行了各种测量，每隔 10 分钟收集一次数据，为时 30 天。这产生了大量数据，包含超过 3.2 亿个数据点，引发了许多需要进一步研究的问题。
例如，阿里云流量是否可以自由穿越中国国家防火墙？AWS Global Accelerator 的表现是否始终优于互联网？哪些关键领域常出现性能异常？为什么会这样？不过，还是先来看看今天的第一个问题，即所有云主干网都相同吗？
提及云主干网时，我们应从两方面进行考察。一是云内部的通信，即考察可用性区域间或地区间的性能；二是与用户的通信。用户流量如何到达云服务？主干网在这方面的使用情况如何？使用方式是否相同？
我们将从地区间测量入手。去年首次进行这项研究时，我们发现 AWS、Azure 和 GCP 在地区间通信中广泛使用自己的主干网。
我们首先测量了各大云提供商在不同地区间进行通信时的延迟，然后将其与相同地区之间不经过云提供商主干网而是通过互联网传输流量的延迟进行比较。在这里可以看到，我们将这两种情况下的地区间通信数据分组，分为表现优于互联网和劣于互联网的组别。
仔细观察中间的三个竖条，分别代表 AWS、Azure 和 GCP，不难发现它们在大约 90% 的地区表现相当出色。我们再来看看 IBM。IBM 在这方面表现异常出色。97% 的地区间通信性能优于互联网，只有 3% 不如互联网。
再向右看阿里云，可以发现其性能与 IBM 截然相反。阿里云有 15% 的地区性能没有互联网那么好。他们的性能不如互联网。我们不禁要问，这是为什么？
经过深入研究，我们发现阿里云是唯一一家没有广泛使用自己的主干网进行地区间通信的云提供商。这意味着什么？也就是说地区间通信要途经互联网。在许多情况下，阿里云在不同地区之间的连接要依靠互联网。
如果企业将应用托管于这家云提供商，应用可能会分布在不同地区，企业务必知悉这可能会影响性能，并且需要了解流量途经的不同网络。
再来了解一下可用性区域间的性能。去年，我们对 AWS、GCP 和 Azure 进行了可用性区域间性能测试，发现这些提供商确实可以做到名副其实。这三家提供商表示其可用性区域间延迟不到 2 毫秒，事实确实如此，而且性能越来越出色，其中 GCP 处于领先地位。
IBM 和阿里云表现如何呢？虽然不能与其他三家相提并论，但也非常出色，可用性区域之间的延迟分别为 1.68 毫秒和 1.22 毫秒。
构建可用性区域是为了在一个地区内实现冗余和容错。如果一个可用性区域发生故障，其他可用性区域可以代为接管，因此应用仍然可用，不会对用户造成中断。
研究相关数据后，我们发现所有云提供商的延迟都低于 2 毫秒。其中一些数据点尤为突出。我们注意到，有两个地区的延迟数值非常低。可以看到，每个圆圈中都填充有数字，表示从相应地区测量的延迟结果。
我们注意到 GCP 在一个地区的可用性区域间延迟为 0.37 毫秒，而阿里云在这一地区的延迟为 0.27 毫秒。这些延迟非常低，不禁令人有些疑问。提供商是如何构建这些可用性区域的？它们是物理上独立的区域，还是同一数据中心内的不同楼层？
虽然这些延迟数值很亮眼，但不禁引人疑问：这些提供商在构建可用性区域时是否采用了不同的方式？企业在使用可用性区域或进行地区间通信时，应向云提供商询问可用性区域的构建方式，而不能想当然地认为 AWS 的可用性区域和其他提供商是一样的，这种想法可能是错误的。
我们讨论了云提供商内部的情况，讨论了不同地区间以及不同可用性区域之间的通信情况。现在来看看用户流量如何到达这些地区。
去年，我们发现用户流量通过两种明显不同的路径进入云提供商主干网。第一种是以互联网为主的传输方式。这意味着什么？这意味着，用户流量会在互联网中传输较长时间，然后才进入云提供商的主干网。
例如，如果一位法兰克福的用户要访问新加坡的服务，在这种以互联网为主的架构中，流量将通过互联网传输到香港，然后进入云提供商的主干网。
另一种方法是“主干网友好型架构”，其中用户流量会进入最靠近用户的提供商主干网。这意味着什么？用户流量在互联网中传输的时间较短，在云提供商主干网中传输的时间则较长。
以上是两种不同类型的连接方式，但我们却发现了三种不同的方法。去年我们发现 Microsoft Azure 和 GCP 采用“主干网友好型架构”来接收用户流量，而且至今仍然如此，这意味着这两家提供商更多地使用自己的主干网。AWS 和阿里云则采用以互联网为主的传输方式。
IBM 呢？研究发现，IBM 采用混合型传输方式。混合型是指 IBM Cloud 在一些地区采用“主干网友好型架构”，比如华盛顿特区；而在另一些地区则采用以互联网为主的方式，比如印度金奈。
我认为我们需要了解并解答的最重要问题是，这些架构对性能有何影响？互联网并不是为了企业通信而打造的，而且互联网也没有 SLA。根据定义，互联网是一种“尽力而为”的网络。这是否意味着，以互联网为主的架构或云提供商可能会出现性能不稳定的情况？让我们一探究竟。
去年，我们注意到 AWS 以互联网为主的架构在全球部分地区频发性能不稳定的情况。如图中所示，横轴上是从用户位置连接到印度孟买云提供商的网络延迟的双向测量结果。
仔细观察亚洲地区，便会注意到 AWS 在这个地区的网络延迟比另外两家提供商要高得多。请留意每个长条上的黑色竖线，这表示网络延迟的偏差，也就是在我们收集数据期间网络延迟的波动情况。
或者可以理解为，要准确或一致地预测性能是否达到平均延迟水平，具体有多大把握。竖线越长，预测的准确性越低。
AWS 的竖线最长，表明可预测性最低，特别是在亚洲地区。为什么亚洲尤其容易出现这种情况？这是因为亚洲的互联网质量不如其他地区，因此容易发生性能波动。
既然如此，这种情况能改善吗？是有可能改善，还是 AWS 在亚洲的性能就是如此？事实证明，这是可以改善的。大家现在看到的是 2018 年和 2019 年的数据对比情况。我们在完全相同的观测点，监控了同一托管地区相同的指标。
AWS 在两个方面有所改进。一方面，亚洲观测点的结果表明网络延迟有所降低；另一方面，我们之前谈到的表示波动的黑线也相对较短。既然可以改进，问题就来了，为什么可以改进？于是，我们研究了路径可视化。
图上显示的是亚洲首尔和新加坡这两个地点的用户连接到印度孟买 AWS 的情况。可以看到，流量从首尔到孟买，绕了全球一圈，经过纽约，然后传输到孟买。
难怪去年亚洲地区 AWS 的网络连接耗时和延迟都很高，因为这不是一条最优路线。现在来看看流量分别在互联网以及 AWS 主干网上花费的时间。这会有一定的变化。
今年再观察这些地点时，我们注意到了一些变化，比如路由经过了大幅优化，还引入了一些对等体位置和主机托管，这表明 AWS 一直在改进并试图影响用户进入主干网的方式。
诚然，利用互联网开展业务难免存在风险，但现在已经有所改善，这就引出了下一个问题。互联网的确存在风险，性能不太稳定，但这是否意味着，主干网友好型云网络能够为性能问题提供万能解药？Azure 和 GCP 的部署就会安全无虞，不会出现性能异常？事实并非如此。
我们注意到，2018 年，AWS、GCP 和 Azure 的网络延迟存在明显差异。要让欧洲用户连接到印度孟买，GCP 所花时间是 AWS 和 Azure 的三倍。
经过进一步调查，我们找出了造成这种情况的原因。GCP 强烈坚持使用自己的主干网来传输用户流量。去年，我们注意到 Google 的主干网并没有直接从印度到欧洲或从欧洲到印度的路线。GCP 解决这个问题的唯一方法就是避开这个问题，这也解释了为什么他们的网络延迟是其他提供商的 3 倍。
在年初开始这项研究时，我们非常好奇会发现哪些变化，因为观察每年的变化正是这项研究的目标之一。我们注意到，变化不大。
Google 正在不断改进其主干网，优化基础设施。然而，这些措施的作用尚未显现出来。在对欧洲同一组地点进行观测后，也并未发现改善。
来看看 Azure 的情况。Azure 在去年表现非常优秀，他们使用了自己的主干网。无论是从网络延迟，还是从延迟的波动方面来看，Azure 表现都非常出色。我们想知道这一年他们发生了哪些变化。看起来好坏参半。
大家现在看到的是性能或延迟波动的变化。我们之前讨论过这种波动，它表示您预测性能时的准确性。柱条越长，可预测性越低。柱条越短越好。
悉尼 Azure 的可预测性明显提高，提高了 50%。但是印度的情况并非如此，反而下降了 30%。
到目前为止，我们了解到了什么？以互联网为主的架构是可以改进的。各大云提供商主干网在架构方面的差距会影响延迟和性能，更改主干网架构可能会带来喜忧参半的结果。
接下来，我们以架构为出发点，将注意力转向全球在互联网方面具有高度自主权的地区：中国。中国国家防火墙对性能有何影响？
今年，我们在报告中新增了阿里云，希望解答“阿里云流量能否自由穿越中国国家防火墙”这一问题。我们对此进行了测试。我们再次从网络延迟和丢包的角度来测量性能。
网络延迟遵循光速原则。例如，如果从中国连接到某托管地区，延迟大致会处在我们对这些提供商的预期范围内。丢包情况很有意思。我们注意到，无论是哪家云提供商，进出中国的流量都会受到影响，发生丢包情况，从而影响性能。
大家现在看到的是，从全球不同地区将流量传输至印度这五家提供商的托管位置时的丢包率，不难发现，来自中国的所有流量都会发生严重的丢包情况。
在这个特殊情况下，我们还测试了从我们在中国的观测点连接到阿里云中国托管地区的性能，没有发现丢包情况，这意味着只要在中国国家防火墙范围内，性能便不会受到影响。一旦越过这个边界，就会遇到丢包和性能问题。阿里云流量并不能自由穿越中国国家防火墙。
发生这种情况的原因在于，中国在互联网连接方面相对独立，就像一个孤岛一样。从中国将流量传送到其他提供商时，只有在穿越中国国家防火墙之后才发生交换。无论是哪家提供商，都不例外。无论是性能还是流量影响，中国都表现得相对中立。
然而，如果由于某种原因不想在中国设立托管，怎么办？如果仍然需要为中国客户提供服务，但又不太愿意选择中国作为托管地区，怎么办？我们从性能出发，研究了可能作为不错选择的地区。
结果发现香港是一个不错的选择。无论是阿里云，还是 Azure，将香港作为托管地区时，在网络延迟方面都表现得相对出色。虽然丢包情况在所难免，但在延迟方面不相上下。新加坡也是一个不错的选择。我们注意到，在新加坡，阿里云处于领先地位，其次是 Azure 和 AWS。
我们一直在关注亚洲的性能。如果仔细查看报告，便会发现拉丁美洲也存在很多异常情况。接下来我们要回答的问题是，哪些可以算是成熟市场？在谈到云提供商的性能时，是否存在一些成熟市场？分别是哪些市场？这些市场是否不受性能异常的影响？
2018-2019 年研究表明，北美和西欧是云性能表现非常出色的市场。所有五家云提供商的表现都非常出色，这些市场很成熟。但是，它们是否不受性能异常的影响？这将是我们接下来要探讨的问题。
我们将转向研究宽带 ISP 到云提供商的连接性能。过去我们一直关注最终用户或连接到云提供商的用户，而现在我们将关注来自不同宽带 ISP 观测点的用户。
这幅图显示了美国五座城市的性能数据， 包括从 AT&T 到 Verizon 的 ISP 连接到美国东部 Azure 托管地区的情况。总体上都比较出色。当然，这些提供商的延迟可能存在差异，但以毫秒计，可以忽略，无需担忧。
但是，是否整个美国、不同云提供商、不同云服务地区都是这种情况？答案是，大多数情况下都是这样。当然不排除异常情况的存在，例外在所难免。
我们注意到，从我们托管在 Verizon 的观测点传输流量至 GCP 在洛杉矶的位置时，往返大约需要 60 毫秒。无论是位于洛杉矶、西雅图还是圣何塞，Verizon Agent 在同一海岸内进行数据传输往返至少需要 60 毫秒。这是一个非常惊人的数字，表明可能存在异常情况。
同样，我们不得不问，为什么会这样？研究表明，这种异常是由路由问题所致，在将流量传输到 Google 网络时，需要从托管于 Verizon 的观测点传输至新泽西州，然后再返回洛杉矶。难怪会出现 60 毫秒的延迟。
在本次研究过程中，收集到的这些数据表明，这个问题确实持续了几个月，但现在已经不复存在。这说明了什么问题？这说明即使是最成熟的市场，即使是最成熟的云提供商或宽带提供商，也可能遇到异常情况，但这只是暂时的。
如果缺乏数据支撑，无法了解良好性能的标准或偏离良好性能的程度，很有可能在云领域盲目行动，茫然无措。
最后，AWS Global Accelerator 是一项专门用于提高 AWS 工作负载性能和可用性的服务。如果没有对它进行研究，任何一份云性能报告都称不上完整。
我们于去年 11 月左右发布了报告。在我们发布报告两周后，AWS 在其 reInvent 大会上推出了一项旨在提升性能的新服务。这并非巧合。
我们对这项服务进行了评测，研究了使用和未使用 Global Accelerator 时的性能情况，以确定是否存在差异。我们观察了网络路径，观察了这两种情况下的丢包、延迟和抖动情况。结果有何发现？
我们发现，Global Accelerator 并非改进性能的良药。换言之，实际效果可能因连接起点、用户所用网络、连接的 AWS 地区等因素而异。性能存在一定差异。
例如，这是在使用位于阿什本的 AWS Accelerator 服务的情况。先来看看首尔用户。利用 AWS Accelerator，从首尔进行连接，性能有所提升，但仍然有 80 毫秒的延迟。这一数字非常惊人，有些不可思议。看来 Global Accelerator 确实能够发挥作用。
再来看班加罗尔，延迟增加到了 100 毫秒。如果用户位于班加罗尔，Global Accelerator 可能不是最佳选择。旧金山情况如何？旧金山的改进微乎其微。
我们需要记住，虽然 Global Accelerator 会通过 AWS 的主干网将流量引导到不同的路径，但是无论如何，延迟都无法超越光速。我们无法改变物理规律。要想缩短延迟，势必会受到限制。
在旧金山，抖动方面也没有改进。问题是，如何确定？如果没有数据，在部署这样的服务之前，如何进行验证？
再次强调，Global Accelerator 或任何云服务的性能取决于用户的位置及其所使用的网络。这幅图只是简略描述。
报告中将提供同样的这一组数据，比较了来自全球 38 个地区的用户位置连接到 AWS 五个地区的性能情况。其中不但提供了延迟改进的绝对值，还会提供相应的改进百分比。
回到我们最初讨论的问题，在云市场竞争激烈的情况下，您如何靠云制胜？有三种方法。首先，从数据出发，杜绝想当然的假设。提升云性能没有简单的套路可循。报告中虽提供了丰富的数据，但只是皮毛而已。
每个云部署都像雪花一样独一无二，因此在分析数据时，需要从自身实际情况出发，选择最符合自己情况的观测点的数据。您可以利用本报告作为初始参考，但在实际部署时，需要依赖真实的数据，而不是基于假设。
其次，采用就绪性生命周期方法。云领域并非一成不变，我们已经分析了这一点。性能可能提升，也可能下降；Accelerator 可能会提升性能，也可能没有作用。如果事先了解到这些信息，获得可视性，就能更好地在云环境中运营。
最后，与提供商建立责任制。这是因为我们发现在成熟市场也可能会出现异常情况，而在不那么成熟的市场中，这些异常可能会反复发生。
如果您可以获得可视性和数据，您可以与云提供商合作，帮助他们改善服务，因为在竞争激烈的市场中，为消费者提供更出色的服务符合提供商的最大利益。因此，请利用数据建立责任制。
回到我们的问题，如何靠云制胜？您可以通过以上三种方法靠云制胜，在高度互联的世界中蓬勃发展。谢谢！
