《架构真经：互联网技术架构的设计》水平扩展

雨点打透心脏的1/2处 2022-01-27 08:13 324阅读 0赞

本节书摘来自华章出版社《架构真经：互联网技术架构的设计》一书中的第1章，第3节，作者 小象学院　杨　磊，更多章节内容可以访问云栖社区“华章计算机”公众号查看。

水平扩展

在实践中，我们经常告诉客户，“向上扩展注定会失败”。这是因为在超高速增长的环境里，公司计划以水平方式扩展（又称之为向外扩展）至关重要。大多数情况下，这是通过对跨越多个系统工作负荷的拆分或者复制完成的。数据拆分的实施，类似我们在第2章中描述的众多方法中的一种，当超高速增长的公司无法扩展时，他们唯一的选择就是购买更大和更快的系统。当由最昂贵的系统提供商所提供的最快和最大的系统遇到扩展瓶颈时，这些公司就遇上了大麻烦。这是1999年eBay受到伤害的根本原因，十多年后的今天我们仍然能够在客户的业务中看到它的影子。扩展的限制和矛盾不仅是物理问题。它们更多是由逻辑争用所引起的，更大和更快的硬件根本无法解决。在深入讨论这个话题之前，让我们先听听一位首席技术官是如何从防火墙的实施过程中吸取这方面教训的。

克里斯·施瑞穆斯是医疗财务管理公司ZirMed的首席技术官，他们提供的服务使医疗保健组织能够通过一个全面的端到端平台，在优化其收入的同时保障患者们（客户）的健康。因为ZirMed系统需要处理患者的敏感数据（PII），所以受到医疗电子交换法案（HIPAA）的约束，克里斯和他的团队设计的数据中心网络具有非常严格的防火墙策略。系统的网络层和应用层之间的通信需要通过防火墙。克里斯回忆道，“我们原来的设计要求部署两套非常强大的防火墙，可以透视产品中的每个子网。在公司规模很小的时候，系统运行得很不错。每当系统接近容量阈值时，可以不断地添加硬件设备来扩大容量。于是我们不停地购买更大的设备。从早期非常小的设备开始，到后来持续不断地向上扩展。在最终改变防火墙设备模式之前，已经变成两个巨大的运营商级别的设备了。这些设备每箱配备了四个刀片服务器。”

两台设备被配置成高可用性（HA）模式，供应商声称这种配置允许服务在故障发生时可以无缝转移。不幸的是，ZirMed的产品在会话期间依赖状态，并且会话状态无法在一对防火墙之间做优雅失败的平滑配置。克里斯继续说，“防火墙供应商一直在跟我们说，在机箱之间有一个高速网络，可以保持所有的套接字和会话，因此可以完成无缝故障转移。但是他们所说的无缝与我所说的无缝完全不同，因为每次应用失败都会出现套接字短暂停止连接的问题，所以造成网络服务器在尝试重新连接数据库时出错。事实上，直到这时候我们才知道供应商配置了相对积极的故障转移策略。如果设备运行中单机配置，该策略只在系统出现危机的最后一步重新启动，而当它在高可用配置下配对运行时，就更加积极，当主机上有风吹草动时，会启动故障转移把防火墙转移到备机。所以系统在双节点高可用状态运行时，设备的故障率比单节点运行时高。这反过来给应用带来了很多麻烦。”

因为其实施的复杂性，ZirMed还被防火墙的其他问题所困扰。“我们使用内容可寻址存储系统，它依赖于网络多播协议，消息要跨越所有的节点，以通知它们。”克里斯解释说，“我们尝试过把那部分拆分出来，而且自认为已经拆出来了，但实际上并没有做到。所有的UDP（用户数据报文协议）流量都要通过防火墙。最终，UDP流量把防火墙压倒了，结果连发出的连接请求都无法进入刀片服务器，因为我们无法看到这一点，所以不得不把供应商请过来查看。这个系统太过复杂，有底盘，还有很多刀片服务器分布在各处，我们搞不清楚这个系统是如何工作的。”

克里斯和他的团队开始讨论，是否应该选择不同的供应商，购买另外一对更大的防火墙，但是后来他们有些如梦方醒。克里斯说，“当构建软件时，我们清楚地知道必须要向外扩展而不是向上扩展。为什么在购买硬件的过程中不采用相同的方法呢？正是这个简单的问题使团队彻底改变了思路。最终，我们从越来越大的全面防护变成现在针对性很强和更小的防火墙实施。”

在ZirMed的新设计中，他们实施了四对防火墙。虽然略多，但从管理角度来看，设备本身要简单得多。在这里我们再次看到了令人不安的“复杂性”。更多的设备等于系统更复杂，因为更多的设备需要更多的管理和监督。但是从另外一个角度来看，更多的设备等于更低的复杂性，因为总体故障率降低，需要管理的事件减少。“我们现在有更小的设备，供应商们知道如何把它们构建得非常非常好，”克里斯指出。“这些防火墙很简单。我们完全掌握这些设备。它也使我们对这些设备上运行的内容了解得更多，更重要的是，现在的设计允许设备数量从4个增加到6个、8个、10个或12个，或任何我们需要的容量。我们还可以继续添加单个设备，隔离出不同的网络分区。当然，我们必须做一些防火墙规则的调整，但是它允许我们在硬件层向外扩展，而不是向上扩展。”

向外扩展而不是向上扩展的好处很多。克里斯总结说：“我们已经看到了巨大的胜利，胜利太多，甚至以我们不太明白的方式取得成功。我们计划把研发环境建立防火墙规则的工作交给应用技术团队。他们没必要是防火墙专家。他们可以动手建立防火墙规则然后通过评审，因为我们知道在这些规则被推送到生产环境之前，网络工程师将会审查，因为我们广域网的防火墙阻止了外部的流量，所以这么做并没有增加风险。这不仅让扩展更加灵活，而且也使防火墙的管理更加灵活，这些体现在把能力有效地赋予团队。”

听了克里斯是如何意识到向外而不是向上扩展的重要性，现在让我们讨论一下有关这个主题的一些规则。本章将围绕着如何把系统设计为水平扩展，而非向上扩展的思路展开讨论，包括使用商品化硬件，以及如何把这个概念应用到数据中心。

规则10——向外扩展

内容： 向外扩展是通过复制或拆分服务或数据库而分散事务负载的方法，与此相对的是向上扩展，即通过购买更大的硬件而实现的扩展。

场景： 任何预计会迅速增长或想追求低成本高效益的系统、服务或数据库。

用法： 用AKF扩展立方体因地制宜确定正确的拆分方法，通常最简单的是水平拆分。

原因： 以复制数据和功能为代价实现事务的快速扩展。

要点： 让系统向外扩展，为成功铺好路。期待能向上扩展，结果却发现自己跑得越来越快，已经无法再购买到更快和更大的系统，千万不要掉进这个陷阱。

当客户和事务快速增长，而系统却无法扩展到多台服务器时，该怎么办？在理想的情况下，可以分析各种选项，不是购买更大的服务器，就是投入研发资源使产品可以在多台服务器上运行。能在所有层级上让产品运行在多个服务器上叫做向外扩展。不断地在更大的硬件上运行任何层级的系统就是向上扩展。在方案分析中，可能会根据投资回报率（ROI）决定购买更大的服务器，而不是投入研发资源来修改应用，因为这么做的成本更低。虽然我们认为决策分析的方法较好，但是，对快速增长的公司和产品来说，这样的决策有缺失，以我们的经验，即便是对温和增长的公司，这样的决策也存在问题。

这样的分析中最常见的错误是，未能分析底层硬件和基础设施的更新换代周期。把一台64位服务器的处理器从两个八核升级到四个八核，从成本比例上看与得到的计算资源改进一致（大致是成本的两倍，改善结果有可能略低于阿姆达尔定律所估算的两倍）。当我们继续购买更大的有更多处理器的服务器时谬误就出现了。成本与计算处理能力的曲线是一个幂律，较大服务器所带来的处理能力的增加与成本增加不成比例（见规则11）。假设公司不断取得成功和成长，你将继续沿着曲线购买更大的系统。虽然可能预测技术更新的时间，但将被迫在一个令人难以置信的高价位购买系统，相反，如果有水平扩展的架构，那么就可以购买相对更便宜的系统。总的来说，总资本支出明显增加。通过投入技术资源解决这个问题的成本当然会随着代码规模和系统复杂度的增加而增加，但这个成本应该是线性的。因此分析的结论应该是立即花时间修改代码以向外扩展。

使用某大型服务器供应商所提供的在线定价和配置实用程序，图3-1中显示了七台服务器的成本，除了处理器及其内核越来越多外，服务器的其他配置（内存、磁盘等）都尽可能相近。不可否认，从计算资源角度看，两个四核处理器不完全等同于一个八核处理器，但成本比较接近。请注意数据模拟线呈指数趋势。

图3-1　单位核的成本

根据我们400多个客户的经验，这种分析的结论几乎总是修改代码或数据库，实现向外而非向上扩展。多种技术的更新周期，要求大型服务器反复不断地投入资本，使问题更加严重，从而促使购买交易的达成。这就是为什么向上扩展就是向上失败，这是AKF合作伙伴的信念。向上扩展最终会停在一个点，要么是成本太高，要么是没有更大的硬件。例如，我们有一个客户有能力将其用户分散到不同的系统里，却继续向上扩展其数据库硬件。他们最终停在首选硬件供应商提供的六个最大的服务器上。这些系统的单价超过300万美元，全部六台服务器的硬件成本接近2000万美元。随着客户需求的增加，该客户挣扎着继续向上扩展，他们开展了一个数据库水平扩展的项目。采用四台单价35万美元的较小的服务器替换那些大型服务器。最后，他们不仅成功地向外扩展继续为客户服务，而且实现了近1000万美元的成本节省。该公司继续使用旧系统，直到最终过期报废，然后以成本较低的较小的系统替换。

大多数应用要么从一开始就可以在多个服务器上运行，要么可以很容易地修改以适应多服务器的情况。大多数的SaaS应用可以通过简单地复制代码到多个应用服务器，然后把它们配置在负载均衡器的后面来实现。应用服务器彼此之间不必互相通知，从负载均衡器发来的请求可以由任何一个服务器来处理。如果应用必须跟踪状态（参见第10章有关为什么要消除状态），一个可能的解决方案是负载均衡器允许使用会话cookie，以维持客户的浏览器和特定的应用服务器之间的关系。一旦客户提交了初始请求，相应的服务器继续服务该客户直到会话结束。

对数据库进行扩展往往需要更多的规划和技术工作，正如我们在开头解释的那样，这是要花费精力的。在第2章中，我们涵盖了三种应用或数据库扩展的方法。在AKF扩展立方体中被标示为X、Y和Z轴，分别对应着复制（克隆），拆分不同的东西（服务），拆分类似的东西（客户）。

你可能会反驳，但这是真的。“英特尔的联合创始人戈登·摩尔在1965年预测，放置在集成电路上的晶体管数量将每两年增加一倍。”摩尔定律已经惊人地保持了超过50年而屹立不倒。正如戈登·摩尔在2005年接受采访时承认的那样［1］，这条定律不可能永远成立。另外，如果贵公司是真正的超高速增长公司，客户或交易的增长速度会比每两年翻一番更快，贵公司可能是每个季度翻一番。此外，阿姆达尔定律暗示不可能获得摩尔定律的全部好处，除非耗费大量的时间优化可以并行的解决方案。如果依靠摩尔定律来扩展系统，那么无论是应用还是数据库都很有可能失败。

规则11——用商品化系统

（金鱼而非汗血宝马）

内容： 尽可能采用小型廉价的系统。

场景： 在超高速增长的生产系统采用该方法，在比较成熟的产品中以此为架构原则。

用法： 在生产环境中远离那些庞大的系统。

原因： 可快速和低成本增长。只采购必要的容量，不浪费在尚未明确的容量需求上。

要点： 构建能够依靠商品化硬件的系统，不要掉进高利润和高端服务器的陷阱。

超高速增长可能是一个孤独的领域。有那么多的东西需要学习，而可供学习的时间又非常有限。但请放心，如果接受我们的建议，你就会有很多的好朋友——那些消耗电力、散发热量、扰动空气、努力赚钱的电脑朋友们。而在超高速增长的世界里，我们相信拥有很多低成本的小“金鱼”要比拥有几只高成本的“纯种”汗血宝马更好。

在本科的微积分教科书里有几行我最喜欢的字，“对漫不经心的旁观者来说，这应该是显而易见的<插入一些完全不起眼的文字>。”

这个特别声明给我留下了深刻的印象，主要是因为对我来说作者当时所呈现的既不直观也不明显。拥有大量较小的电脑看起来似乎并不比拥有少量庞大的系统更有优势。事实上，更多的计算机可能意味着更多的电力、空间和冷却需求。多且小经常比少且大好的原因有两个，本章后面会详细介绍。

设备供应商受益于把利润最高的产品卖给你。几乎对于每个供应商来说，具有最高利润的产品往往是处理器最多的最大的产品。为什么会是这样？许多公司依靠更快和更大的硬件来完成必要的处理工作，却不愿意在扩展自己基础设施的地方投入。因此，设备制造商把这些公司当成人质索要更高的价格和利润。但是这里面有个有趣的问题，与有同等数量处理器的较小系统相比，这些更快和更大的机器并非真正能够做更多的工作。以CPU为例，这些机器比较小的系统拥有更少的处理能力。在添加CPU时，每个CPU的工作量比单CPU的系统（不考虑核数）少。这有很多原因，包括多处理器调度算法的低效率、内存总线访问速度冲突、结构障碍、数据障碍等。在虚拟化环境中，管理虚拟机的开销随着物理机规模的增加而增加。效率最佳的似乎是两个CPU或四个CPU的物理主机。

仔细回顾一下我们刚才说过的话，你花钱买进更多CPU，但实际上每个CPU所做的事情却更少，供应商总共盘剥你两次！

当与以前的信息冲突的时候，大多数提供商很可能会在第一阶段否认。聪明的供应商会迅速改变说法，指出整体拥有成本将会下降，因为较大服务器比较小服务器消耗的电力比较少。他们可能会说，你可以与某伙伴合作，通过把系统分区（或虚拟化），来获得小系统消耗较少电力的好处。这使我们意识到：必须算算账。

实际上，更大的系统可能会消耗更少的电力并降低成本。随着电力成本的增加和系统成本的降低，毫无疑问系统存在着合适的规模，可以最优化电力消耗、系统成本和计算能力。供应商绝不是信息的最佳来源。你应该自己算清账。算账的结果绝对不会促使你购买市场上能买到的最大的系统，因为这并不划算。为了弄清楚应该如何回应供应商的论点，我们把它们分解成几个组成部分。

我们把电力成本和单位电力消耗，与独立第三方的系统利用率基准数据进行比较。仍然可以找到在适合范围内的商品化硬件（也就是说还没有被供应商作为高端系统加价），然后最大化计算能力，同时满足最小电力和空间的要求。几乎在所有情况下，当考虑所有成本时，整体的拥有成本通常会下降。

关于虚拟化，请记住没有免费的软件。虚拟化（域或分区）的理由很多。但是将系统虚拟化成四个单独的域，与购买四套规模相当的系统相比，永远不会获得更大的处理能力和吞吐量。因为虚拟化必须利用CPU的资源来运行，而这些资源一定要有它的出处。另外，在比较大的分域系统中的大系统容量，与同等规模的小系统容量相比是一个错误。

促使我们使用商品化系统而不是昂贵系统的其他原因是什么？虽然我们积极计划扩展，但是扩展速度是有成本的。对商品化硬件我们更容易谈判。虽然我们可能有很多这种系统，但是丢弃它们也很容易，而且可以随心所欲地安排工作，而比较昂贵的系统则需要花大量的时间去掌握。虽然这似乎有些难以理解，但是，与比较昂贵的系统（汗血宝马）相比，我们已经成功地使用较少的人管理更多的商品化系统（金鱼）。我们维护这些系统的成本较低，而且也可以负担得起更多的系统冗余，因为每个单元上的部件（例如CPU）较少，系统失败的机会也比较低。

最后，让我们来解释一下为什么把这些东西称之为“金鱼”。因为这些系统非常便宜，如果它们“死掉”，你可能会轻松地丢弃它们，而不是投入大量的时间来修复。另一方面，“汗血宝马”代表了相当大量的投资，因此需要时间来维护和修复。最后，我们更喜欢有很多的小朋友，而不是几个大朋友。

规则12——托管方案扩展

内容： 把系统部署到三个或更多活的数据中心，以降低总体成本、增加可用性并实现灾难恢复。数据中心可以是自有设施、托管或云计算（IaaS或PaaS）实例。

场景： 任何正在考虑添加灾难恢复数据中心（冷备）的快速增长的业务，或希望通过三数据中心方案优化成本的成熟业务。

用法： 根据AKF扩展立方体来扩展数据。以“多活”方式配置系统。使用IaaS/PaaS（云计算）来解决突发容量问题，新投资或者作为三数据中心方案的一部分。

原因： 数据中心故障的成本对业务的影响可能是灾难性的。三个或更多个数据中心的解决方案的成本通常比两个数据中心少。考虑使用云计算作为部署之一，高峰流量来临时向云扩展。拥有基础流量的设施；租赁解决高峰流量的设施。

要点： 在实现灾难恢复时，可以通过系统设计实现三个或更多个活跃数据中心以降低成本。IaaS和PaaS（云计算）可以快速地扩展系统，应用于高峰需求期。通过系统设计确保如果三个数据中心中只要两个可用，则功能完全不受影响。如果系统扩展到三个以上数据中心，则为N-1个数据中心可用，功能完全不受影响。

数据中心已成为迅猛发展公司扩展的最大痛点之一。因为数据中心需要长时间的规划和建设，而且经常是在快速增长期间我们所想到的最后几件事情之一。有时候我们想到的“最后一件事”往往就是使我们的公司陷入最危险境地的事情。

建设和运行数据中心所需要的核心能力很少与某个技术团队重叠；避免拥有自己的数据中心，直到公司的规模大到可以通过建设和运行自己的数据中心来节省成本成为可能。在成长期间使用托管和云计算提供商；让他们承担数据中心的操作风险以及数据中心建设的计划。通过自有数据中心实现成本节约的最低有效数据中心的规模大约是3MW的IT容量——约相当于9000个双插槽的服务器。构建这样的数据中心，对使用标准化设计和设备经验丰富的公司需要12个月，对选择使用新设计和新设备的公司需要24个月。根据指定设施的冗余级别，所需资本从3000万美元到5000万美元不等。建设和运行数据中心并不是一个简单的任务。避免建设和运行自己的数据中心，直到公司规模大到自建数据中心划算的时候。

此条规则是针对“如何”和“为什么”拆分数据中心以应对快速增长的简要回答。

首先，让我们回顾几个基础。为了故障隔离（有助于高可用性）和事务增长，我们想要使用在规则8和规则9中分别给出的Y轴和Z轴拆分的方法。为了高可用性和事务的增长，我们将按照规则7所述的沿X轴复制（或克隆）数据和服务。最后，我们将假设你尝试过应用第10章中介绍的规则40，要么有一个无状态的系统，要么可以绕过有状态的需要而允许多数据中心部署。正是对数据和服务的这种拆分、复制和克隆以及无状态，奠定了分散数据中心并使其跨越多个设施和地区的基础。标准化的系统配置、代码部署和监控使托管网站和云计算网站之间可以实现无缝扩展。

如果沿着Z轴适当地拆分数据（见规则9），我们就可以潜在地将数据定位到更靠近请求数据的用户。如果在拆分数据的同时保持以个人用户为单位的多租户模式，那么我们就可以选择靠近最终用户地理位置的数据中心。如果服务的最小单位是公司，我们也可以定位在所服务公司的旁边（如果它是一个大公司，至少是那些公司中员工最多的办公室）。

让我们从三个数据中心开始。每个数据中心大约是33%数据的“家”。我们将其称为数据集A、B和C。每个数据中心的每个数据集都有一半数据被复制到对应的数据中心。假设做Z轴拆分（见规则9）和X轴数据复制（见规则7），数据中心A中客户数据的50%会存储在数据中心B，另外的50%将存储在数据中心C。如果任何数据中心失败，失败数据中心中50%的数据和关联的事务将会被转移到其对应的数据中心。如果数据中心A失败，其数据和事务的50%将被转移到数据中心B，另外的50%被转移到数据中心C。如图3-2所示。结果是运行系统总共需要200%的数据，每个数据中心只包含66%的必要数据，每个数据中心包含主备两份拷贝，主拷贝（运行系统所需数据的33%）和其他每个数据中心副本的50%（在总共33%的额外数据中运行系统需要16.5%）。

图3-2　数据中心复制的拆分

让我们做些计算来了解为什么这个配置比其他方案更好。假设发生地理上孤立的灾难事件，我们需要至少两个数据中心存活。有分别标记为A和B的两个数据中心，你可能决定数据中心A处理所有的流量，数据中心B做冷备份。在热/冷（或主动/被动）配置中，两个数据中心都需要配置100%的计算和网络资产，其中包括100%的网络和应用服务器、100%的数据库服务器和100%的网络设备。电力和互联网连接的需求也与此类似。每个数据中心可能需要保持略微超过服务所需容量的100%来处理需求激增所带来的峰值流量。假设两个数据中心各保持110%的容量。当为一个数据中心购买额外的服务器时，也必须为另外一个数据中心购买。你也可能决定使用自己的专线连接两个数据中心，以确保数据复制的安全。运行两个数据中心将有助于在发生重大灾难时存活，因为在灾难发生最初会有50%的交易失败，直到将流量转移到备用数据中心，但是从预算或财务角度它帮不了忙。数据中心可能的宏观设计如图3-3所示。

图3-3　双数据中心配置，“热”和“冷”

但是三数据中心的解决方案可以降低成本。因为对所有的非数据库系统，在系统发生故障时，每个数据中心只需要具备150%的容量就可以运行100%的流量。无论采用什么方法数据库都需要200%的存储，无法降低成本。电力和设施消耗大约也是单个数据中心需求的150%，显然需要更多的人来应付三数据中心的需求，这个开销可能比150%略高。唯一不成比例增加的地方是网络互联，因为三个数据中心比两个数据中心需要两个额外的连接（而不是一个）。数据中心的新配置如图3-4所示，相关运营成本的比较见表3-1。三个数据中心中的任何一个都可以是云数据中心，这也可以减少运营需要增加的人员。

图3-4　三数据中心配置，三个热数据中心

表3-1　成本比较

配置 网络 服务器 数据库 存储 节点互连 总成本

单数据中心 100% 100% 100% 100% 0 100%

冷热双数据中心 200% 200% 200% 200% 1 200%

双活双数据中心 200% 200% 200% 200% 1 200%

三活三数据中心 150% 150% 150% 200% 3 ～166%

如上所述，选择三个数据中心而不是两个可以减少硬件成本25%（从峰值的200%需要降到150%）。据此推断需要50台服务器以满足高峰期需求，企业应该购买51台服务器并把它们托管在51个不同的数据中心。从学术角度来看，这的确最小化了硬件支出，但是试图使用这么多网站所带来的网络和管理成本的增加使这个想法显得十分荒唐。

三数据中心配置的一个很大的好处是能够利用空闲容量创建测试区（如负载和性能测试），以及在需求高峰期间利用这些闲置资产的能力。这些尖峰几乎随时可以发生。这也许是因为一些特殊的和计划外的新闻发布，也许只是某个关系格外良好的个人或公司有一些令人难以置信的瞬间流量刺激。手头上的灾备能力开始获得流量，我们很快开始购买额外的容量！

正如我们所暗示的，运行三个或更多的数据中心也有一些缺点。因为所有数据中心都是活的，每个数据中心都在发挥作用，所以也带来了一些额外的操作复杂性。我们认为，虽然有些额外的复杂性存在，但是并不比运行热／冷数据中心显著。保持两个数据中心同步很困难，特别是团队没有机会验证单一数据中心在需要的时候是否可以发挥作用。继续运行三数据中心有些挑战，但并不是特别难。

即使其他成本最终下降，网络传输成本仍以相当快的速度增长。对于完全连接的数据中心拓扑，每个新节点（N+1）都需要N个额外的连接，其中N是先前的节点数。公司通常通过协商批量折扣和压低第三方传输供应商成本，从而妥善地处理这笔费用。另一个选择是将流量转发到对等网络以优化成本和性能，特别是当流量的峰值不规则或显著大于基线流量的时候。这需要仔细分析可能带来的好处以及转发到对等网络的成本。

当然，利用好IaaS的弹性，你就不需要“拥有”一切。一种做法是分别在三个地理位置（如亚马逊AWS的“地区”）“租赁”一个数据中心。或者采用混合的方法，保持托管设施和自有数据中心的混合，然后动态增加，即按季节或每天根据需求扩展到公共云。

最后，基于多活数据中心的模型，我们可以预见员工及其相关成本会增加。如果数据中心的规模很大，我们可能会将员工安排居住在数据中心的附近，而不是依靠远程工作。即使现场没有员工，我们也可能需要不时地前往数据中心去验证设置、与第三方合作提供商配合等。如果有一个数据中心是云，那么不太需要现场工作，因此可以潜在地缓解工作人员的增加。随着服务器总数的增长，标准化的配置、部署工具和监控将有助于优化员工数量。当进行成本核算时，使用多个数据中心还有其他的好处，如确保数据中心接近最终客户减少页面加载时间。下面总结了多活数据中心实施的优点、缺点和架构考虑。

多活数据中心要考虑的因素

多活数据中心的优点包括：

比热-冷数据中心配置有更高的可用性。

比热-冷数据中心配置有更低的成本。

动态路由到附近的数据中心使客户的响应时间更快。

在SaaS环境中推出产品有更大的灵活性。

在操作上比热-冷数据中心配置有更大信心。

特别是当PaaS/IaaS /云计算是整体解决方案的一部分时，利用闲置资源轻松快速地“按需”增长以应付突然出现的流量高峰。

多活数据中心的缺点包括：

更高的操作复杂度。

人员数量少许增加。

出差和网络成本增加。

建立多活数据中心的架构考虑因素包括：

尽可能消除对状态的需要。

尽可能减少动态调用，将客户路由到最近的数据中心。

研究数据库和状态的复制技术。

规则13——利用云

内容： 有目的地利用云技术按需扩展。

场景： 当需求是临时的、突增的、偶发的，响应时间不是产品的核心问题。要将其当成是“租用风险”——新产品对未来需求的不确定性，需要在快速改变或放弃投资间抉择。公司从双活向三活数据中心迁移时，云可以作为第三数据中心。

用法：

采用第三方云环境应对临时需求，如季节性业务变动、大的批处理任务或者是测试中需要的QA环境。

当用户请求超过某个峰值时，把应用设计成可以从第三方云环境对外提供服务。扩展云以应对高峰期，然后再把活跃的节点数减少到基本水平。

原因： 在云环境中配置硬件需要几分钟，在自己的托管设施配置物理服务器需要几天甚至几周。当临时使用时，云的成本效益非常高。

要点： 在所有网站中利用虚拟化，并在云中扩展以应付意想不到的突发需求。

云计算是许多供应商提供的IaaS产品的一部分，例如亚马逊、谷歌、IBM和微软。供应商提供的云主要有四个特征：按使用付费，按需要扩展，多租户和虚拟化。第三方云通常由许多运行系统管理（hypervisor）软件的物理服务器组成，可以模拟较小的虚拟服务器。例如具有32GB内存、8个处理器的机器可以虚拟成4台机器，每台允许使用两个处理器和8GB的内存。

客户可以使用其中一台虚拟服务器，并且根据他们使用时间的长短收费。提供这些服务的每个供应商的定价不同，但通常使用虚拟服务器与购买物理服务器的盈亏平衡点大约是12个月。这意味着如果连续12个月每天24小时使用服务器，花费将超过采购物理服务器的成本。如果这些虚拟服务器可以基于需求启动和停止，那就可能节省成本。因此，如果每天只需要这个服务器工作六个小时完成批处理任务，那么盈亏平衡点就会延长到48个月。

成本当然是决定是否使用云的重要因素，云的另外一个明显优势在于系统的准备通常只需要几分钟，而物理硬件的系统准备则要用天或周来计算。公司购置额外硬件需要批准、订购、接收、上架和加载，很容易花上几个星期。在云环境中，添加额外的服务器可以在几分钟内完成。此外，托管中心可能没有空间来容纳新的硬件，因此需要等待新机架的建设，这又会延迟交货时间。

使用第三方云环境的公司有两种理想方式，就是当需求是临时的或不一致的时候。临时需求可以以夜间批处理作业的形式出现，需要几个小时的大量计算资源或每个月为发布下一个版本会周期性地进行几天QA测试。不一致的需求可以通过促销或者网络星期一的季节性的形式出现。

我们有一个客户每晚都充分利用第三方云环境来处理当天的数据，并把处理好的数据加载到数据仓库。他们运行数百个虚拟实例，处理数据，然后关闭实例，确保只支付自己所需要的计算资源量。另一个的客户为他们的QA工程师提供虚拟实例。他们为要进行测试的软件版本构建机器映像，然后当QA工程师需要一个新环境或刷新后的环境时，分配一个新的虚拟实例。因为使用虚拟实例作为QA环境，不会出现几十个测试服务器处在大部分时间无人使用的状态。我们的另一个客户，当他们的需求超过一定程度时，使用云环境来提供广告服务。存储的数据每隔几分钟同步一次，所以从云平台提供的广告服务几乎和那些从托管设施服务的广告一样。这个特定的应用在处理数据同步时可能有轻微的延迟，因为在请求时投放广告，即使不是绝对最好的广告，仍然要比因无法扩展而没有投放广告好。

云的另一个有吸引力的特性是它是“租赁风险”的理想选择。如果贵公司是一个新的创业公司，不确定市场是否会对产品有需求。或者，贵公司是一个成熟的公司，有新产品计划，想满足现有市场或未来市场。也许你正在给现有产品添加功能并以现有解决方案单独部署的形式提供服务，但不确定客户是否愿意采用该功能。这些案例都代表着风险——客户不愿意接受任何产品构建的风险。在这些例子中，租赁有风险产品的系统容量更有意义，因为如果有风险你可以轻松地抛弃它，而不需要消耗硬件的费用。

想想你的系统，哪些部分最适合云环境？通常有些组件，诸如批量处理、测试环境或峰值容量，把它们放在云环境更有意义。因为云环境允许根据需要在非常短的时间范围内实现按需扩展。

总结

虽然向上扩展是个适合中慢速增长公司的选择，但那些增长速度持续超过摩尔定律的公司，将会在毫不知情的情况下，突然发现自己所拥有的高端昂贵的系统的计算能力遭遇极限。我们见过的几乎所有影响大的服务故障都是同一个原因，产品自以为“了不起”。我们相信，提前做好扩展计划，以便在需求出现时可以轻松地拆分系统是明智的。按照我们的规则扩展系统和数据中心，利用云来处理意外需求，依靠廉价的商品化硬件，为超高速成长做好准备！

注释

1. Manek Dubash, “Moore’s Law Is Dead, Says Gordon Moore,” TechWorld, April 13, 2005, www.techworld.com/news/operating-systems/moores-law-is-dead-says-gordonmoore-3576581/.