脑洞大开：将非死book整个托管在AWS上，这可行吗？
jopen 7年前
<p style="text-align: center;"><a href="/misc/goto?guid=4958985142605832856" title="云计算"><img alt="脑洞大开：将非死book整个托管在AWS上，这可行吗？" src="https://simg.open-open.com/show/99fa9929e5ad6b3b83beee4d3f4d1414.gif" /></a></p> <p>非死book 大约在<a href="/misc/goto?guid=4959009422564073488">2004 年成立</a>，随着逐渐成为<a href="/misc/goto?guid=4959009422677376288">美国五大科技巨头</a>之一，他们的基础架构也由大学寝室里的一台服务器发展成为遍布全球的<a href="/misc/goto?guid=4959009422764023539">七个</a>定制数据中心。随着 非死book 预计用户数将增长至 19.4 亿，他们很有可能还在规划新的数据中心。</p> <p>最近公布了一则消息：Snap 分别与 <a href="/misc/goto?guid=4959009422859768897">Google Cloud Platform</a> 和 <a href="/misc/goto?guid=4959009422945038890">AWS</a>（Amazon Web Services）签署<a href="/misc/goto?guid=4959009423031630596">价值 20 亿和 10 亿美元订单</a>，这使得我们不禁好奇，以 非死book 如此庞大的规模，能否在 AWS 之上运行。</p> <p>为了回答这个问题，我们从四个方面来考虑：</p> <ol> <li>服务器容量</li> <li>服务器硬件性能</li> <li>软件</li> <li>成本</li> </ol> <p>请注意，我们考虑的不是 非死book 是否应该迁移至 AWS，只是在探讨这样做的可行性。</p> <p><strong>1. 服务器容量</strong></p> <p>由于 非死book 已经很久没有公布过准确的服务器数量，很多人根据流传的假设进一步进行了猜测。不过这里肯定水分不少。</p> <p><strong>非死book 到底有多少台服务器？</strong></p> <p>早在 2012 年，Data Center Knowledge 估计 非死book 共有<a href="/misc/goto?guid=4959009423118908690">180,000 台服务器</a>。这个数值基于 2010 年发布的一组数据，通过这组数据<a href="/misc/goto?guid=4959009423214213846">精确计算</a>得知，非死book 在 2010 年共有 60,000 台服务器。假设 2012 年的估值是准确的，那么 非死book 的服务器数量增速已经远远超过了<a href="/misc/goto?guid=4959009423290531086">摩尔定律</a>。</p> <p style="text-align:center"><img alt="脑洞大开：将非死book整个托管在AWS上，这可行吗？" src="https://simg.open-open.com/show/89471f5b6d0a38979789113c40016c81.png" /></p> <p style="text-align:center">非死book 的用户增长情况，来源：<a href="https://simg.open-open.com/show/927daed7e5252a0f9fcdd6ecd756a280.png">The Next Web</a></p> <p>我们想知道 非死book 在五年（2012-2017）后的今天有多少台服务器。为了获得尽可能精确的估值，我们进行了三种计算。</p> <p><strong>计算一：每服务器用户数</strong></p> <p>首先通过“每服务器用户数”来计算 非死book 的服务器数量。</p> <p>2012 年，非死book 用户数 10 亿，共有 18 万台服务器。</p> <ul> <li>1,000,000 用户 / 180,000 服务器 = 5,556 用户每服务器</li> </ul> <p>2017 年，非死book 用户数接近 20 亿。</p> <ul> <li>2,000,000 用户 / 5,556 用户每服务器 = 360,000 台服务器</li> </ul> <p>此外还需要考虑，非死book 不仅用户数翻倍，每个人生成的数据量也增加了：照片、视频、直播等。另外现在 非死book 还运营着 Instagram，那么服务器数量再翻一倍吧。</p> <p>360,000 * 2 = 720,000 服务器</p> <p>按照这个计算方式，非死book 在 2017 年拥有的服务器数量约为 72 万台。</p> <p><strong>计算二：每服务器营收</strong></p> <p>接下来通过“每服务器营收”来计算他们的服务器容量。</p> <p>2012 年，非死book 营收为<a href="/misc/goto?guid=4959009423390413400">50. 89 亿美元</a>。将 2012 年的营收除以 2012 年的服务器总量，那么每服务器营收为 2.8 万美元。</p> <ul> <li>5,089,000,000 美元营收 / 180,000 服务器 = 28,272 美元营收每服务器</li> </ul> <p>2016 年，非死book 营收为 276.38 亿美元，将其除以 28,272 美元，那么就是 977,575 台服务器。</p> <ul> <li>27,638,000,000 美元营收 / 28,272 美元营收每服务器 = 977,574.98 台服务器</li> </ul> <p>按照这个计算方式，非死book 在 2017 年拥有的服务器数量约为 97.8 万台。</p> <p><strong>计算三：每服务器对应的员工数</strong></p> <p>这个方式将使用员工数来计算服务器容量。</p> <p>2012 年，非死book 有<a href="/misc/goto?guid=4959009423479983838">4,619 名员工</a>，平均每位员工对应约 40 台服务器。</p> <ul> <li>180,000 服务器 / 4619 员工 = 38.96 台服务器每员工</li> </ul> <p>2016 年，非死book 有 17,048 名员工。按照每位员工 40 台服务器来计算，约有 681,920 台服务器。</p> <ul> <li>17,048 员工 * 40 服务器每员工 = 681,920 台服务器</li> </ul> <p>按照这个计算方式，非死book 在 2017 年拥有的服务器数量约为 68.2 万台。</p> <p><strong>不同数量之间的差异</strong></p> <p>三种计算方式的区间为 296,000。</p> <p>978,000 - 682,000 = 296,000</p> <p>取中间值并将其作为我们最终的数量。</p> <p>296,000 / 2 = 148,000</p> <p>682,000 + 148,000 = 830,000 或 978,000 - 148,000 = 830,000</p> <p>所以我们估计 非死book 在 2017 年共有 830,000 台服务器。</p> <p><strong>AWS 又有多少台服务器？</strong></p> <p style="text-align:center"><img alt="脑洞大开：将非死book整个托管在AWS上，这可行吗？" src="https://simg.open-open.com/show/83960ce6f750885f73143135a51acff0.png" /></p> <p style="text-align:center">AWS 的全球基础架构，来源：AWS</p> <p>AWS 可以按照下列方式分解：</p> <ul> <li>地区 – 一个完整包含的地理区域（如“欧洲”或“美国西部”）。</li> <li>可用区域（AZ） - 地区内由一个或多个数据中心组成的不同区域（如“伦敦”或“俄勒冈”）。</li> <li>数据中心 – 基本上就是一种大面积，造价高昂的仓库，每个数据中心承载<a href="/misc/goto?guid=4959009423561762608">5 万至 8 万台服务器</a>。</li> </ul> <p>截止 2017 年，AWS 共有：</p> <ul> <li>16 个地区（还有 3 个在建）。</li> <li>42 个 AZ（新地区上线后还将增加 8 个）。</li> </ul> <p>相关信息可参阅 <a href="/misc/goto?guid=4959009423656872842">AWS 全球基础架构</a>介绍。</p> <p>假设平均每个数据中心有 6.5 万台服务器，平均每个 AZ 有 1.5 个数据中心，那么服务器的总数为 409.5 万台。四舍五入一下，假设 AWS 共有 410 万台服务器。</p> <p>(42 AZ * 1.5 个数据中心) * 65,000 台服务器 = 4,095,000</p> <p>2014 年，Enterprise Tech 进行过<a href="/misc/goto?guid=4959009423742078750">类似的计算</a>（不过是基于 28 个 AZ，但道理是相通的），最终估计的服务器数量介于 280 万到 560 万台之间。他们的估算中，每个 AZ 包含三个数据中心，如果这个假设是准确的，那么 AWS 在全球范围内可能会有超过 800 万台服务器。</p> <p><strong>服务器净容量</strong></p> <p>在服务器净容量方面，根据上文（可能不准确的）计算，AWS 规模是 非死book 的 5 倍。</p> <ul> <li>非死book 需要 83 万台服务器</li> <li>AWS 有 410 万台服务器</li> <li>4,100,000 / 830,000 = 4.939</li> </ul> <p>补充说明：上述计算并未考虑 AWS 目前的容量局限。AWS 的日常运营有多少预留容量？AWS 是否有 20% 的预留容量可以分配给 非死book？我们打算忽略这些问题，直接假设 AWS 可以完全容纳 非死book 目前的需求，但可能要牺牲灵活性作为代价。</p> <p>为了满足未来对服务器的需求，非死book 和 AWS 都在服务器基础架构方面进行持续不断的投入，因此可以认为，未来的 AWS 也足以承载未来的 非死book。</p> <blockquote> <p>在服务器净容量方面，非死book 有可能托管在 AWS 上吗？</p> </blockquote> <p>很可能是可以的。</p> <p><strong>2. 服务器硬件性能</strong></p> <p>不能直接假定 AWS 与 非死book 的服务器性能是相等的，因此还要考虑服务器性能的问题。非死book 在服务器基础架构方面已经投入了数十亿美元，随着规模逐渐增长，他们经历了一台笔记本充当服务器，从第三方租用服务器，再到自建数据中心的过程。当他们开始自行设计并构建数据中心时，拆箱即用的解决方案就不再适合了。</p> <p style="text-align:center"><img alt="脑洞大开：将非死book整个托管在AWS上，这可行吗？" src="https://simg.open-open.com/show/0af36d8d7a9c1a24b16f903f149b0537.jpg" /></p> <p style="text-align:center">非死book 在建的沃斯堡（Fort Worth）数据中心，来源：DataCenter Knowledge</p> <p>非死book 七个数据中心在各方面都以最大化性能和效率为设计目标。从数据中心整体设计到各种细节，例如服务器机架和芯片，一切都是定制的。</p> <p>“为了优化成本，我们淘汰了你能在标准服务器上看到的大部分组件”，非死book 服务器的设计者 Amir Michael 在<a href="/misc/goto?guid=4959009423819636699">2009 年</a>这样说过。</p> <blockquote> <p>“我们拆掉了所有没用的东西，只保留最必要的。”</p> </blockquote> <p>2011 年，非死book <a href="/misc/goto?guid=4958196354510108215">开源了</a>自己有关数据中心和服务器的全部设计，借此表达对高效率设计的热爱。随后还有很多人对该项目做出了贡献，包括 Google。这些举措也推动了硬件成本的进一步降低，开始有第三方制造商生产相关组件，进一步降低了定制化数据中心的建设成本。你可以访问 <a href="/misc/goto?guid=4959009424093052556">Data Center Knowledge</a> 查看完整的 非死book 服务器硬件清单。</p> <p>因此 非死book 现有的服务器基础架构已经得到了大幅优化，可以帮助 非死book 尽可能高效地运营。例如，他们在服务器场中开辟了一块单独的“<a href="/misc/goto?guid=4959009424173949462">冷存储</a>”，专门用来保存不再有人查看的照片和视频（通常都是 10 年前上传至 非死book 的内容）。只有在有人想要查看这些照片或视频时，才会“唤醒”这种存储设备。</p> <p>这段 油Tube <a href="/misc/goto?guid=4959009424260501191">视频</a>展示了 非死book 的冷存储设置。</p> <p>非死book 多年的专精化运营与 AWS 截然不同，AWS 的存储在设计上就需要考虑不同用途（高负荷）的使用。但是与 非死book 和 Google 类似，Amazon <a href="/misc/goto?guid=4959009423561762608">也自行设计硬件</a>。</p> <p>“没错，我们会自己制造服务器，”Amazon CTO <a href="/misc/goto?guid=4959009423561762608">Werner Vogels</a> 说：“我们会通过自行制造的定制化存储和服务器满足这些（重量级）工作负载的需求。我们还与 Intel 合作制造以更高<a href="/misc/goto?guid=4959009424355779804">时钟频率</a>运行的自用处理器。”</p> <p>虽然 AWS 可能显得更加通用化，不过他们服务器的实际表现不可能比 非死book 差。然而关于专用化以及效率，大家有很多不同看法，这些大型科技公司为什么要这样做？假设真的要迁移，为了能通过 AWS 获得与自己数据中心类似的性能，非死book 很有可能需要更多服务器。为了体现这种因素，并在缺乏实际数据的情况下进行对比，我们假设 非死book 迁移后需要的服务器数量会比目前增加 10%，因此服务器的数量将增至 91.3 万台。</p> <p>830,000 * 1.1 = 913,000</p> <p style="text-align:center"><img alt="脑洞大开：将非死book整个托管在AWS上，这可行吗？" src="https://simg.open-open.com/show/948a529419d8c351932f14592fdbcec0.jpg" /></p> <p>非死book 的普莱斯维尔（Prineville）数据中心内部，来源：DataCenter Knowledge</p> <p>另外还要注意，非死book 正打算<a href="/misc/goto?guid=4959009424431497258">将 WhatsApp 从 IBM 平台迁出</a>，转移至自己的服务器上运行。WhatsApp 目前使用了 700 台裸机（类似于 非死book 的）高端 IBM SoftLayer 服务器，这些服务器基本上可以提供与 非死book 自有硬件类似的性能。但相比我们之前讨论的一切，这个数字（700！）实在是微不足道，那么可以假设这方面未来的增长完全可以包含在他们未来的扩展计划中。</p> <p><strong>迁移？</strong></p> <p>现实中，非死book 完全不可能迁移至 AWS。因此这次开脑洞的过程并不考虑有关迁移的具体过程，我们只是想探讨一下这样做的可行性。实际上本文全文都基于这样的一个假设：非死book 从开始自建基础架构的第一天开始就选择托管在 AWS，结果将会怎样。</p> <p>权且假设我们在一个平行宇宙中，那么迁移到 AWS 的工作是否顺利，需要多久？非死book 在 2013 到 2014 年间将 Instagram 从 AWS 迁移到了自己的服务器上，整个过程用了一年，并且<a href="/misc/goto?guid=4959009424524250002">无人察觉</a>。结合这件事来考虑，我们应该也可以在最终用户毫无察觉的情况下进行反向迁移。</p> <p>然而…… 我们要迁移的可是整个 非死book，还包括 Instagram，因此整个过程肯定需要更长时间。相比这种理论上的迁移，Instagram 的迁移规模就小太多了，更无须说之前迁移后 Instagram 的规模也扩大了不少。另外别忘了 Netflix，他们花了<a href="/misc/goto?guid=4959009424617276743">八年</a>才彻底迁移至 AWS。八年啊！</p> <p>基于这些假设和猜测，迁移过程应该会很顺利，但可能需要多年时间才能完成。</p> <p><strong>服务器硬件性能</strong></p> <p>AWS 和 非死book 都在定制数据中心、服务器设计，以及实施方面进行了大量投入。在所有设计均已开源的情况下，这两家的服务器性能很可能不相上下。</p> <p>我们认为 AWS 可以很轻松地提供 非死book 所需的计算能力和性能。但因为 AWS 无法满足 非死book 某些特殊需求，因此还需要保留一些余量。非死book 用 830,000 台自有服务器可以做到的事情，换成 AWS 的服务器可能需要 913,000 台。</p> <blockquote> <p>AWS 能提供 非死book 所需的服务器性能吗？</p> </blockquote> <p>极为可能毫无问题。</p> <p><strong>3. 软件</strong></p> <p>非死book 曾经（并且目前依然）使用 OSS（开源软件）进行开发。与其他公司类似，他们的增长速度飞快，以如此大的规模来说，通常都需要自行开发定制工具，或对现有工具进行大量修改才能满足自己的需求。</p> <p>他们依然使用 PHP 开发应用程序代码，但为了提高性能，非死book 开发了 <a href="/misc/goto?guid=4958847603829461554">HipHop Virtual Machine</a>（<a href="/misc/goto?guid=4959009424737154751">HHVM</a>），借此通过即时编译（JIT）的方式编译 PHP 代码。这意味着 非死book 的代码可以通过配合使用 HHVM 和 nginx 的方式来运行。<a href="/misc/goto?guid=4959009424822325439">非死book 的整个网站运行在 HHVM 之上</a>（桌面、API、移动），开发和生产环境均是如此。而这恰恰就是定制化的软件。</p> <p>感觉上，AWS <a href="/misc/goto?guid=4959009424901383389">与 PHP 和 HHVM 的关系让人担忧</a>。但在 非死book 自己的 <a href="/misc/goto?guid=4959009424986378882">HHVM GitHub 代码库</a>中，有一个链接指向了 <a href="/misc/goto?guid=4959009425076496229">HHVM for AWS Linux 服务器</a>。因此我们可以假设 非死book 可以成功地在 AWS 上运行 HHVM，进而运行自己的网站。</p> <p style="text-align:center"><img alt="脑洞大开：将非死book整个托管在AWS上，这可行吗？" src="https://simg.open-open.com/show/a2bd6de2d3c815fb19435a0803788e8d.png" /></p> <p>但是数据库呢？数据存储方面，在 <a href="/misc/goto?guid=4959009425161280129">SQL 与 NoSQL 对战</a>中有一个臭名昭著的例子：非死book 对 <a href="/misc/goto?guid=4959009425248836264">MySQL</a> 进行了大刀阔斧的改动，用于存储自己的<a href="/misc/goto?guid=4959009425329705654">时间线</a>数据，同时依赖 <a href="/misc/goto?guid=4959009425415754267">memcached</a> 实现快速交付。有关 非死book 的伸缩，建议阅读 <a href="/misc/goto?guid=4959009425509808151">High Scalability</a> 的相关文章。非死book 定制版 MySQL 的规范可参阅<a href="/misc/goto?guid=4959009425594529711">这里</a>。</p> <p><a href="/misc/goto?guid=4958971672411705521">Amazon RDS</a>（Relational Database Service）可以满足要求吗？有很多科技巨头都在使用 Amazon RDS，最著名的就是 Netflix。也许可以认为，如果 Netflix 以及他们公司的所有视频都可以成功地通过 RDS 运行，那么 非死book 也可以？答案无法确定，不过 非死book 的 MySQL 集群是极为庞大的，简单地迁移很可能根本无法满足需求。为了处理自己的负载，他们甚至创建了自己的 MySQL 分支！</p> <p>目前 非死book 也已构造出极为全面的<a href="/misc/goto?guid=4959009425713506069">技术栈</a>。他们的 <a href="/misc/goto?guid=4958530808118738847">GitHub 代码库</a>足以证明这一点。这不免让人更担心他们的基础架构与 AWS 的兼容性问题。</p> <p>这一过程到底会有多难，<a href="/misc/goto?guid=4959009424617276743">Netflix</a> 的例子也许是最好的证明，随着迁移至分布式云环境，他们需要重建大部分技术组件。</p> <blockquote> <p>AWS 能够支持 非死book 庞大的软件环境和复杂的数据需求吗？</p> </blockquote> <p>也许可以，但几乎可以肯定这样做会让性能大受影响，非死book 甚至可能需要构建一个新的系统。</p> <p><strong>4. 将 非死book 托管到 AWS，成本会有多高？</strong></p> <p>注意：这可能是本文准确性最差的内容。虽然 AWS 提供了丰富的成本计算方法，但我们无法获知 非死book 对数据存储和计算的实际需求。再次提醒，这些数据完全基于猜测。</p> <p>我们好奇的最后一个问题：成本。虽然 AWS 已经帮助无数公司快速低成本地缩放，但他们中的绝大部分永远无法达到 非死book 的规模。以 非死book 的规模来说，自建基础架构可能更便宜（他们也正是这样做的，但我们就是想开个脑洞 ^.^）。</p> <p>在使用 <a href="/misc/goto?guid=4959009425838910023">AWS 自己的成本计算器</a>进行计算前，先来看看一些全球化产品在云计算方面的成本。</p> <p>Snapchat 的 IPO 文件中提到，Snap 公司计划在 5 年里向 <a href="/misc/goto?guid=4959009425924398080">Google</a> 支付 20 亿美元，同时向 <a href="/misc/goto?guid=4959009423031630596">AWS</a> 支付 10 亿美元。也就是说，每月 5 千万美元。如此巨大的数字让技术界有些吃惊，甚至有人编出了“支付高额费用存储并处理很快会被销毁的内容”这样的段子（译注：Snapchat 是一种“阅后即焚”应用，用户发送的文字和图片等内容会在收件人查看之后立刻销毁）。</p> <p>上文曾经提到，WhatsApp 依然托管在 IBM 的公有云服务器上，但 非死book 计划尽快进行迁移。然而目前 WhatsApp 的托管成本依然高达每月 2 百万美元。对于一个只使用了 700 台服务器的应用来说，这个成本实在是有点高。</p> <p>我们可以假设 非死book 的用量需求远高于 WhatsApp 和 Snapchat 的总合。</p> <p><strong>成本计算</strong></p> <p>下列计算较为简单，基于1,000,000 台服务器，这些服务器分别运行 EC2 计算、Amazon S3、Amazon RDS，以及照片和视频等数据的存储和传输任务，每月传输的数据流量为1,256.5PB（1,256,500TB）。</p> <p>计算中假设：</p> <ul> <li>每天上传 3 亿张照片，平均每张照片 4MB。</li> <li>每天上传 1 亿小时的视频，平均每个视频 200MB。</li> </ul> <p>这些计算即不精确也不严谨。如果你有更好的计算方法，欢迎自己试一试！原始的 AWS 成本计算结果可参阅<a href="https://calculator.s3.amazonaws.com/index.html#r=IAD&key=calc-03140D3B-00A9-404C-85D6-BA52A304BFC6">这里</a>。</p> <p>随后开始计算：</p> <p>Amazon EC2</p> <p>计算：Amazon EC2 实例（用于运行 PHP 代码等内容）</p> <ul> <li>实例：713,000 个</li> <li>每月 100% 利用率</li> <li>r3.2xlarge 实例上运行 Linux</li> <li>3 年全额预付</li> </ul> <p>Amazon S3</p> <p>存储（照片和视频）</p> <ul> <li>标准存储：1256.5PB</li> <li>PUT/COPY/POST/LIST 请求：2147483647 个</li> <li>GET 和其他请求：2147483647 个</li> </ul> <p>数据传输</p> <ul> <li>区域间数据传出：314125</li> <li>数据传出：628250</li> <li>数据传入：1256500</li> <li>数据传出至 CloudFront：1256500</li> </ul> <p>Amazon RDS</p> <p>Amazon RDS On-Demand DB 实例（用于运行 非死book 的时间线）</p> <ul> <li>数据库实例：200,000 个</li> <li>每月 100% 利用率</li> <li>数据库引擎和许可：MySQL</li> <li>实例类型：db.r3.2xlarge</li> <li>部署：多 AZ</li> <li>存储：常规用途，1TB</li> </ul> <p>数据传输</p> <ul> <li>区域间数据传出：500TB</li> <li>数据传出：500TB</li> <li>数据传入：500TB</li> <li>区域内数据传输：500TB</li> </ul> <p>总额</p> <ul> <li>一次性全额支付（3 年期预付）：3,933,846,000.00 美元（39 亿）</li> <li>一次性全额支付分摊至 36 个月：每月 109,273,500.00 美元（1.09 亿）</li> <li>排除一次性支付，额外的月成本：389,020,939.96 美元（3.89 亿）</li> <li>月总成本：109,273,500.000 美元（1.08 亿）+ 389,020,939.96 美元（3.89 亿） = 498,293,439.96 美元（4.98 亿）</li> <li>年总成本：5,979,521,279.52 美元（59.7 亿）</li> </ul> <blockquote> <p>理论上，如果托管在 AWS 上，非死book 每年的成本高达 59.7 亿美元。</p> </blockquote> <p><strong>巨头 非死book</strong></p> <p>年<a href="/misc/goto?guid=4959009422677376288">营收</a>超过 280 亿美元，总市值 4340 亿美元，全球用户数超过 19.4 亿的 非死book 无疑有着庞大而复杂的基础架构。有人预计 非死book 在 2012 年时的自有服务器基础架构价值已高达 40 亿美元，目前这一数字很可能已经翻了三倍达到 120 亿美元。</p> <p>然而每年 59.7 亿美元的托管成本已经远远超过 非死book 在 2017 年时的“营收成本”（<a href="http://yahoo.brand.edgar-online.com/displayfilinginfo.aspx?FilingID=11821305-257269-388055&type=sect&TabIndex=2&dcn=0001326801-17-000007">3,789,000,000 美元</a>），这个成本已包含数据中心以及其他方面的运营成本。</p> <p>另外需要注意，假设估算的 AWS 价格可能并非 非死book 需要支付的。与 Snapchat 和 Netflix 类似，非死book 也是有很大影响力的重量级用户，因此有能力协商并获得更低的价格。</p> <blockquote> <p>非死book 能够支付 AWS 托管费用吗？</p> </blockquote> <p>可以，但这样更贵。</p> <p><strong>非死book 有可能托管在 AWS 上吗？</strong></p> <p>我们永远不可能知道这种开脑洞的假设是否准确，但可以这样看：</p> <ol> <li>在服务器净容量方面，AWS 应该可以满足 非死book 的需求。</li> <li>服务器硬件的性能也许并非最优，但只要使用更多服务器获得更强计算能力就可以解决。</li> <li>软件部分最麻烦。需要考虑 非死book 能否简单地将现有基础架构直接移植到 AWS。虽然有可行的解决方案，但可能需要在 AWS 现有基础架构的基础上构建新的系统。这样的做法不仅痛苦，而且不太可行。但如果 非死book 在 2010/2011 年就选择托管到 AWS，那么可能已围绕 AWS 构建了自己的技术，这种情况下软件本身不再是问题，但依然棘手。</li> <li>非死book 可以付得起托管费用，但相比目前的成本会高很多。</li> </ol> <p>毫无疑问，这些结论都是错的，因为我们无法获得计算所需的数据。但是……</p> <p>根据本文进行的计算和得到的结果，理论上可以将 非死book 托管到 AWS 吗？可以，完全可以。</p> <p>作者：<a href="/misc/goto?guid=4959009426207471959">SQLizer 官方博客</a>，阅读英文原文：<a href="/misc/goto?guid=4959009426299537633">Is it possible to host 非死book on AWS?</a></p> <p>来自: <a href="/misc/goto?guid=4959009426378340055" id="link_source2">InfoQ</a></p>