Question

转移到集群化的解决方案需要转变思想。从串行转到我们在第9章中所介绍过的并行代码，是一个需要转变思想的演进。突然间，你不得不考虑当你有超过一台机器时，会发生什么——在机器间会有延迟，你需要知道你的其他机器是否在工作，你还需要让所有机器运行相同版本的软件。系统管理可能是你最大的挑战。

此外，你通常不得不努力思考你要实现的算法以及一旦你拥有了所有这些可能需要保持同步的额外的转移部分，将会发生什么事。这个额外计划可能施加了一个沉重的智商税，可能让你从核心任务中分心走岔，一旦系统成长得足够庞大，你可能需要一个专职的工程师来加入你的团队。

　备忘　

我们尝试集中于有效使用一台机器的理由就是因为我们都相信如果你只处理一台计算机而不是一组计算机，那么生活就会更轻松（尽管我们承认玩弄一个集群会更有趣——直到它失效为止）。如果你能够垂直扩展（通过购买更多的RAM或者CPU），那么就值得调查这种方法对集群的支持。当然，你的处理需求可能会超过垂直扩展所能做的一切，或者一个集群的鲁棒性可能比一台单独的机器更加重要。然而，如果你是独自一个人工作于这个任务，也要记住运行一个集群会消耗你的一些时间。

当设计一个集群化的解决方案时，你需要记住每台机器的配置可能是不相同的（每台机器会有不同的负载和不同的局部数据）。你该如何来把所有正确的数据放到处理你任务的机器上来呢？移动任务和数据涉及的延迟会成为问题吗？你的任务需要和其他任务相互通信部分结果吗？当几个任务正在运行时，如果一个进程失效了或者一台机器挂了或者一些硬件擦除了自己，那么会发生什么呢？如果你不去考虑这些问题，失败就会随之而来。

你也应该考虑到失效是能够被接受的。例如，当你运行一个基于内容的Web服务时，你可能不需要99.999%的可靠性——如果一项任务偶然失效了（例如，一张图片没有足够快速地被缩放），并且需要用户来重载页面，那是每个人都已经习以为常的。那可能不是你想要给予用户的解决方案，但是接受一点失效常常降低了你的边际工程和管理成本，那是值得的。另一方面，如果一个高频交易系统经历了失效，那么为糟糕的股票市场交易所付出的代价可能是相当巨大的！

维护一个固定的基础设施可能变得代价高昂。采购机器是相对廉价的，但是它们具有一个糟糕的变坏的趋势——自动软件更新会有小故障，网卡会失效，硬盘会有写错误，电力供给可能输出损坏数据的尖峰能量，宇宙射线可能反转RAM模块的一个比特位。你拥有越多的计算机，就会损失越多的时间来处理这些问题。你迟早会想要增加一名系统工程师来处理这些问题，因此又增加了100000美元的预算。使用一个基于云的集群能够缓解许多这些问题（它花费更多钱，但是你不必处理硬件维护），而且一些云供应商也为廉价而临时的计算资源提供了一个即时付费的市场。

伴随着集群随时间有机成长而带来的潜在问题就是如果一切都关掉了，可能没有人对怎样安全地重启集群而制定文档。如果你没有一个文档化的重启计划，那你就应该设想你将不得不在可能是最坏的时候来写文档（你的其中一个作者已经卷入到在圣诞夜调试这种类型的问题——这不是你想要的圣诞礼物！）。在这点上，你也会了解到让一个系统的每个组件开始加速可能要花费多久——也许集群的每个组件要花费几分钟来启动并开始处理任务，所以如果你有10个依次运行的组件，可能要花费一小时来让整个系统完成冷启动。结果就是你可能有一个小时之久的堆积数据。那么你有所需的容量来及时处理这些堆积数据吗？

懈怠的行为可能是引起代价高昂的错误的原因，而复杂且难以预料的行为可能导致代价高昂的不可预料的结果。让我们看看两起引人注目的集群失效，并看看我们能够学到的教训。

10.2.1　糟糕的集群升级策略造成华尔街损失4.62亿美元

在2012年，高频交易公司骑士资本在集群中做软件升级期间引入了一个错误，损失了4.62亿美元。软件做出了超出客户所请求的股票买卖。

在交易软件中，一个更老的标记转用于新函数。升级已进行到了8台活跃机器中的7台，但是第8台机器使用了更旧的代码来处理标记，这导致了所做出的错误的交易。安全和交易委员会（SEC）注意到骑士资本没有让其他技术人员来检查升级，并且没有流程来检查已经存在的升级。

根本的错误看起来有两个原因。首先，软件开发过程没有移除一个废弃的功能，所以僵尸代码遗留了下来。第二就是没有人工检查过程来确认升级成功完成了。

技术债最终增添了不得不付出的代价——倾向于在没有压力时花时间来解决技术债。在构建和重构代码时，总是使用单元测试。缺乏一个手写的检查列表在系统升级期间去核对一遍，又缺乏第二双眼睛来检查，可能就会让你付出代价高昂的失败。飞机驾驶员有理由必须要过一遍下降检查列表：这意味着没有人会错过重要的步骤，无论他们以前可能已经做了多少次。

10.2.2　Skype的24小时全球中断

Skype在2010年遭受了一次24小时全球范围的失效。在幕后，Skype由点对点网络所支持。部分系统发生的过载（用来处理线下的即时消息）造成了Windows客户端的响应延迟，一些版本的Windows客户端没有合适地处理延迟的响应就垮掉了。总体上，大约40%的活跃客户端垮掉了，包括25%的公共超级节点。超级节点对网络上的路由数据起关键作用。

随着25%的路由断线（它恢复了，但是缓慢地恢复），整体网络处于严重的压力下。崩溃的Windows客户节点也正在重启中，并且尝试重新加入网络，在已经过载的系统上增加了新的大量的流量。超级节点在经受太多的负载时，有回退步骤，所以它们开始关闭来对流量的波浪做出反应。

Skype变得24小时严重不可用。恢复步骤涉及首先要设置几百台新的万兆超级节点，它们被配置成用以处理增加的流量，接着用几千台更多的新超级节点来跟进。在接下来的几天内，网络恢复了。

事故造成了Skype的很多窘境，显然，在几天紧张的日子里，他们的精力也切换到限制破坏中去了。客户被迫寻找语音电话的可替代方案，可能对竞争者来说是一个市场恩赐。

考虑到网络的复杂性以及发生失效的升级，这个失效可能是难以预测和做出计划来应对的。网络上的所有节点不会失效的理由是因为不同的软件版本和不同的平台——异构网络比同构网络更具有可靠性的收益。