互联网地图的 Web 架构

引言

 

您现在一定听说过 The Internet map。如果没有，您可以在 这里 查看。粗略地说，The Internet Map 根据用户行为显示网站的位置。同一批用户访问的相似网站彼此靠近；没有互访用户之间的不同网站则相距甚远。地图上网站的大小由其平均点击评分决定，颜色则由其国籍决定。您可以通过参考地图网站上的“关于”部分来获得更详细的概念。

 

 

在本文中，我想告诉您 The Internet map 网站是如何组织的，哪些技术确保了其日常正常运行，以及为了承受大量访问者涌入以查看地图而必须采取哪些步骤。

Internet Map 的运行得益于当今互联网巨头们的技术：地图的视觉显示由 Google Inc. 的 Google Maps 引擎提供支持，Web 查询处理由 Microsoft 的 .net 技术执行，而 Amazon Web Services 由 Amazon 负责托管和内容交付。这三个组件对于地图的正常运行至关重要。虽然付出一些努力可以找到替代方案，但我并不确定这会带来多大的好处。

Amazon CloudFront 和 Google Maps

Google Maps 技术意味着使用瓦片——每个瓦片大小为 256x256 像素的小图片，地图图像由这些瓦片组成。这些图片的关键在于它们的数量非常庞大。当您在屏幕上以高分辨率看到地图时，它完全由这些小图片组成。这意味着服务器必须能够同时处理大量小查询并输出瓦片，以便客户端看不到马赛克。显示地图所需的瓦片总数等于 sum(4^i)，其中 i 的取值范围从 0 到 N，N 是缩放的总次数。正如 The Internet map 的情况一样，缩放次数等于 14，即瓦片数量必须约为 3.58 亿。幸运的是，通过避免生成空白瓦片，这个天文数字减少到了 3000 万。如果您打开浏览器控制台，您会看到大量 403 错误，它们就是那里——被遗漏的瓦片，但这在地图上是看不见的，因为如果没有瓦片，该区域会自动填充为黑色背景。无论如何，3000 万瓦片仍然是一个可观的数量。即使在 Windows 中复制或删除带有瓦片的目录也需要 2 天。o_O

因此，将内容放置在专用服务器上的传统方式不适用于此情况。瓦片很多，用户也很多，所以服务器也应该很多，并且它们应该靠近用户，以便他们不会注意到延迟。否则，来自俄罗斯的用户将获得良好的响应，而日本用户在查看您的地图时将回忆起拨号调制解调器时代的时光。幸运的是，Amazon 有一个解决方案（Akamai 也有，但那是另一回事）。它被称为 CloudFront，本质上是一个全球 CDN（CDN – 内容分发网络）。您将您的内容部署在某个地方（称为源站），然后在 CloudFront 中创建一个分发。每当用户请求您的内容时，CloudFront 都会自动找到离用户最近的网络节点，如果它还没有您数据的副本，它将从拥有副本的另一个节点或从源站请求。看起来，您的数据会经过多轮复制，并且很可能从 CloudFront 服务器交付，而不是从您自己昂贵、脆弱且不安全的数据库库中交付。说到 The Internet map，利用 CloudFront 实际上意味着我的硬盘数据被复制到新加坡的 Simple Storage Service (S3) 片段，然后在 CloudFront 中的 AWS 控制台中创建了一个分发，其中 S3 被引用为数据源。如果您查看 The Internet map 网页的代码，您可能会看到瓦片是从以下 CloudFront 地址获取的：http://d2h9tsxwphc7ip.cloudfront.net/；CloudFront 会自动确定最近的节点、更新内容等。太棒了！

在图片中，您可以看到原始地图如何分解成瓦片，瓦片进入 S3 进行存储，然后从那里导入到 CloudFront，并最终从其节点分发给用户。

Amazon CloudFront 和 Google Maps

为了提供在地图上搜索网站的功能，需要一个数据库来存储网站信息及其坐标。在这种情况下，我们在 Amazon 的云中使用的是 MS SQL Express 实例。它被称为关系数据库服务（RDS）。我们实际上不需要关系部分，因为我们只有一个表，但拥有一个功能齐全的数据库总比以后重新发明轮子要好。RDS 不仅支持 MS SQL，还支持 Oracle、MySql 以及可能还有其他数据库。

在图片中，您可以看到原始地图在 RDS 数据库中变成了一个表。

Amazon Elastic Beanstalk

这很可能是所有“云端”Amazon 服务中最让我惊叹的功能。Elastic Beanstalk 让您几乎一键发布一个项目，将其置于负载之下，并且离线时间极短甚至完全不离线。考虑到发布可能多么困难，尤其是当基础设施包含多个服务器和负载均衡器时，Elastic Beanstalk 的轻松优雅管理让我惊叹不已！在第一次部署时，它会创建您的应用程序所需的所有环境：负载均衡器（Elastic Load Balancer - ELB）、计算单元（Elastic Compute Cloud - EC2），它还会确定缩放参数。粗略地说，如果您只有一台服务器，并且所有查询都直接导向它，当达到某个限制时，您的服务器将无法承受负载，很可能会崩溃。有时它甚至无法恢复正常运行，因为它恢复到正常运行模式通常需要一些时间，而在持续查询的背景下几乎是不可能的。无论如何，有过这种经历的人都会明白我的意思。

在所有基础设施方面，您可以信赖 Elastic Beanstalk。事实上，您只需在 MS Visual Studio 中安装一个插件，然后就可以忽略细节了。它将自行控制和更新版本、部署等。并且在负载增加的情况下，它将创建必要的 EC2 实例数量。

在图表中，Elastic Beanstalk 用虚线标出，内部您可以看到 ELB 正在接受传入的查询并将其服务于 EC2 实例中的 IIS。

性能及其成本

The Internet map 于 7 月 24 日上线，当时我在俄罗斯最大的 IT 资源 Habrahabr.ru 上发布了一篇文章。

文章发布后不久，The Internet map 就迎来了大量访问者。从图表中可以看出，网站流量急剧上升，在最初的 6 小时内，该网站有 30,000 人访问，到一天结束时，这个数字几乎达到了 50,000 人，大部分来自俄罗斯和前苏联国家。察觉到异常，Elastic Beanstalk 创建了 10 个 EC2 实例，它们很好地处理了问题。没有收到关于访问网站问题的投诉。地图可以自由查看。至于 RDS，它立即崩溃了，首先搜索开始工作得非常缓慢，然后变得不稳定，最终完全停止工作。第一天的账单约为 200 美元。大约 100 美元用于 S3+CloudFront，EC2 和 RDS 各花费 50 美元。

吸取了教训后，我优化了代码并重新调整了自动缩放参数。这奏效了。在一周内，该网站平均每天有 30,000 到 50,000 人来自不同地区访问，一切顺利。我必须说的是，第一天那种突然的流量激增再也没有发生过。

然后有人在 reddit.com 上发布了一些关于该地图的信息，导致了爆炸性的流量激增。周日，该网站大约有五十万人访问，而此时只有一个小型 EC2 实例和一个小型 RDS 实例运行良好。不过有一个投诉说地图没有加载，但我认为对于这种负载来说是可以接受的。

当我看到如此巨大的流量时，我预料到亚马逊会收到巨额账单，并弹出了捐赠窗口。现在它已经正常了，捐赠几乎可以支付账单了。

这是第一周（约 1,000,000 独立访客）的账单

结论

当我开始从事信息技术行业时，“云端”这个词与 IT 毫无关系。从那时起，情况发生了变化，独立服务器正在走向淘汰。毫无疑问，云托管也有其缺点（例如，问问 Instagram）。然而，在我看来，能够将大部分烦恼委托给云服务的能力，远远弥补了所有风险。如果您正处于项目开发的初期，并且质量、可负担性、可靠性和可扩展性是您的优先事项，您可能应该直接选择云。