| 摘要：本文从计算机领域的“祖师爷”艾伦·图灵提出的图灵机概念开始，介绍了图形计算的概念，并以示例介绍了apache storm，基于apache storm如何进行分布式图形计算。apache storm是一个免费开源的分布式实时计算系统，具有简单易用、快速、可扩展、容错等优点。 介绍 计算可能很复杂。对我们来说，这种复杂主要就是软件世界的人类驱动力。甚至有一个学科整个都围绕着问题解决和计算——计算机科学。 当一个人开始学习计算机科学时，会被介绍一些术语和概念，这些术语和概念都是围绕着试图以可证明，恰当的方式对问题的解决方案进行建模和表达而形成的。
艾伦·图灵 艾伦·图灵 天才地提出了 图灵机 的概念。这些“机器”使我们能够以数学证明的方式恰如其分地描述解决方案，同样也适用于解决计算机科学领域遇到的问题。
图片由 维基本科 提供。 从那时起，围绕抽象计算机（包括图灵机）的整个研究发展起来，名为 自动机理论的研究 。 自动机理论的领域是广泛的，也是在不断增长和最流行的 — 因为它可以生成能够解决现实生活中问题的模型。
图片由 维基本科 提供。 在一定程度上，自动机理论与 图论 是密切相关的。 结合这两种理论的优点，我们能够设计出可证明的、分布式的、有效的解决问题的方案，否则这些问题将会太过于复杂，难以表达和解决。 在本文中，将介绍 Apache Storm （从现在开始使用术语“Storm” – 通常是指Apache的Storm版本。storm中的spout译为“喷嘴”，bolt译为“螺栓”），作为分布式图形计算基础架构的实现。 接下来就开始吧！ 图形计算作为降低系统复杂度的一种方式 在介绍了图灵机、自动机理论和图论之后，图形计算可以作为一种降低系统复杂度的方式吗？ 答案是肯定的。 依靠一个经过测试和证明的模型，并不一定意味着 使用 这个模型和 证明 它一样复杂。 例如下面的表达式： 1 + 1 = 2 大家都“知道”它是正确的，并且能够使用它，因为已经有人 证明 它是正确的。 在本文的例子中，试图将一个已知的问题转化为一个图形计算，其中每个 顶点 都是一个计算单元。根据连接它们的边，在顶点之间“移动”。 接下来看下面的例子： 想要实现一个应用程序执行以下任务：
把手头的任务看作是一个图形计算，可以将其描述如下：
以图形的方式思考问题有一些好处。 首先，有了图形以后，人类的思维更容易理解，不至于那么抽象了。 其次，鼓励我们遵循良好务实的软件设计原则，如 关注点分离 原则。每个顶点只做一件事。 再次，它使我们看到每个顶点所做的事，并将其外包给基础架构。 例如，每个顶点接收并可能发送消息。以 容错 的方式负责 外包 处理 传入和传出消息 是非常可取的。 部署也可以通过这种方式变得 更加灵活 — 例如，可以部署一台单独计算机的每个计算单元，并让基础架构去负责固有的消息传递和分发。 负载均衡和 可扩展性 如何？可以依靠“外部”消息传递系统来管理同一计算单元的多个实例吗？答案是肯定的！ 如果在订单验证过程中遇到瓶颈，是否可以实例化一个额外的验证计算单元并让它处理一些工作呢？可以的。 现在请记住，我们已经在图中描述了应该如何处理每个输入消息。还没有描述过如何部署它。 所以 我们也分开 考虑了软件的 正确性 和软件的 部署 问题。 可能的情况是，除了将实例化两个计算单元的验证顶点之外，还为每个“逻辑”图形顶点实例化一个物理计算单元，如下图所示：
前面提到的关于关注点分离的提示，利用适当的基础架构，可以处理进程间的通信，给出不同的部署需求（每个组织/个人），以容错和可扩展的方式，旨在找准问题。 图形计算确实是有用的，帮助我们考虑软件解决方案，同时把软件部署排除在外 —只要有适当的基础架构，就可以做到这一点。 Apache Storm提供了以图形方式编写计算的能力，同时提供了一个固有的基础架构，使我们能够可靠高效地完成这些计算。 Apache Storm的方式 Apache Storm中，主要应用程序被称为拓扑（topology），也就是Storm拓扑。
每个拓扑代表一个永远在线的应用程序，它可以接收来自被称为 喷嘴 （spout）的数据源的输入。
喷嘴是输入消息的来源，称为 元组 。元组是动态类型的，它的成员可以是任何类型 —只要Storm“知道”如何序列化和反序列化这些类型。
元组正在按照拓扑的定义在 螺栓 （ bolt）之间传递。每个螺栓都可以传递元组到其它螺栓，只要它们连接到它。一个螺栓可以修改一个元组或者创建一个新的元组。它也可以按原样传递传入的元组，或者根本不传递任何东西。
元组通过喷嘴的元组流向被称为 流 。多个流可以共存于一个拓扑中。每个数据流都与其它数据流并行处理。稍后将会再讲到这一点。
Storm极具融合性，并与其它技术很好地集成。它能够使用 Elasticsearch ， Mongodb ， Kafka ， Redis ， Kinesis 等基础架构。如果需要自定义的东西，这也是可能的，Storm有一个很大的并在不断发展的库生态系统。
所以，如果想用一句话总结一下“Storm方式”的话，我会说： Apache Storm是一种分布式技术，旨在允许开发人员利用图形计算模型为问题同时提供“底层”（例如消息负载均衡）和“顶层“（例如准备使用Kafka Spout - 只需配置和使用来自Kafka的数据）的逻辑解决方案。 Apache Storm概述 为了更好地了解Storm如何工作，需要暂时缩小范围。 本文不会对技术本身进行深入地研究。但是，如果想更好地了解该技术，包括部署的演示，与其它技术的集成和监控，请参阅我的课程， 在这里 。 从宏观上看看Storm集群是如何建立的。这将有助于了解它是如何提供上述基础架构的，比如计算图形部分之间的可靠消息传递，以及某种程度的并行性，文章将在后面作进一步解释。 首先，storm集群是由（不足为奇）…节点构建而成的。这些节点可以采用任何一个主节点的形式运行 Nimbus 守护进程或者采用 工作进程（worker）节点的形式 —运行 Supervisor 守护进程。它采用主从架构方式，主节点是Nimbus，从节点是Supervisor，有关调度相关的信息存储在Zookeeper集群中。
主节点负责在工作节点之间分配工作。分配什么工作呢？实现图形计算的实际代码作为拓扑传递给Storm集群。 主节点和工作节点如何相互认知？通过 Zookeeper 。Zookeeper是一个分布式服务，作为一个可靠的配置和同步提供者。要了解更多关于Zookeeper的信息，包括安装和集成演示，请看看 这里 。
所以说主节点负责将代码分发给工作节点。但是，这里还有一个额外的抽象层： 工作进程 。 一个工作 进程 负责执行拓扑的一个子集。每个工作进程将实例化执行 任务 实例的执行器线程。这些任务可以是 喷嘴 或 螺栓 。
虽然理解起来可能相当困难，但是这种结构确实具有在各种物理机器，进程和线程之间分配逻辑计算图形的能力，从而使storm集群在硬件故障的情况下 保持逻辑计算完整性 。 一个工作进程挂了？没问题 —主节点会将其工作分配给另一个工作节点。
请注意，看起来主节点似乎是一个单点故障点。事实并不是这样。即使主节点发生故障或崩溃，拓扑仍将继续执行。显然，我们将无法向集群提交新拓扑，因为主节点有责任在工作节点之间进行代码共享，但是在线计算将继续下去。 这种不希望发生的情况可以通过在Storm集群（又名Nimbus H / A）中定义多个主节点来弥补。这样的话，一个失败的主节点将会被一个健康的主节点替换。 现在应该能够更好地理解Storm是如何将计算图形和 物理 硬件层（主节点和工作节点，zookeeper，执行进程中的工作进程和任务）的 逻辑 概念完全分离开来的（拓扑结构是由喷嘴和螺栓与元组之间的流动建立起来的）。 这种架构是团队之间关注点分离的推动者。可以将处理逻辑层的任务分配给开发人员，也可以将处理物理层的任务分配给DevOps工程师。
开发Storm的工程师考虑了上述关注点分离的概念，并向开发人员提供了在开发人员的机器上 本地运行拓扑 的思路。 谈论开发人员—不如看一些代码？ 示例拓扑—让我们看一些代码 好吧，有些人可能以为在进行订单验证，包装和装运时，这个例子并不太适合演示图形计算。 我不这么认为。图形计算，就像任何其它模型一样都是一个工具。作为开发人员，软件架构师和/或研发副总裁，都需要决定这个工具是否适合手头上的任务。我认为对于高吞吐量的电子商务网站，Storm实际上非常适合作为一个稳定的后台。 接下来看看如何将上述用例作为一个Storm的拓扑实现。 |
