Heron —— 核心组件学习

理解Heron的运行原理很重要，下面学习Heron的核心组件。

Heron 的核心组件
Topology Master

Container

Stream Manager

Heron Instance

Metrics Manager

Heron Tracker

1.Topology Master
Topology Master(TM)用来管理一个topology的提交到被杀死的整个生命周期，当heron部署一个topology时，它就会加载一个TM和多个container。TM会创建一个临时的Zookeeper节点来确保topology中只有一个TM，这样TM会很容易被topology中的任何进程（heron优化了storm中基于线程的方式为进程方式）发现。TM还构建了它涉及到不同组件拓扑的物理方案。


Topology Master配置

TM提供了丰富的可配置参数，我们可以通过这些配置参数调整topology生命周期中的每一个阶段。

2. Container
每一个heron topology都包含了很多container，每一个container里面又包含了一些组件，如多个heron实例，一个Stream Manager和一个Metrics Manager。容器和topology的TM进行通信，从而形成一个完整的连通图。可以参考上面master的图。
3. Stream Manager
Stream Manager(SM) 用来管理topology组件之间的tuple路由。topology中的每个Heron实例和它本地的SM相连接，而在一个既定topology中的所有SM通过彼此连接从而形成一个网络。

下图是一个SM网络结构示意图：


除了作为数据流的路由引擎之外，SM还会在必要时负责topology内的back pressure（反向压力，背压） 传播。下面这个图展示的是back pressure



在上图中，假设容器A中的bolt-B3接受来自spout-S1的所有输入，那么B3就会比其他组件运行的慢。相应的，容器A的SM将会拒绝来自容器C和D的输入，这样的后果就是，会使得这些容器中的socker buffers被写满数据，从而导致崩溃。
这种情况下，Heron的back pressure（背压）机制就会起作用。容器A中的SM会发送一条消息给其他所有的SM，相应的，其他的SM将会检查容器的物理方案，并且隔断从sport流向到bolt的输入。在这个例子中，就是SM会隔断spout-S1流向bolt-B3的数据。



一但滞后的bolt-B3开始正常工作，那么容器A中的SM会通知其他的SM，tolopogy内的数据流路由也会回归正常。

Stream Manager的配置

同样的，SM也有丰富的配置参数来调整topology生命周期中的每个阶段。
4. Heron Instance
Heron Instance（HI）是用来处理spout或者bolt单个任务的进程，它可以很容易进行调试和分析。
注：目前，Heron仅支持Java，所以所有的heron实例都是JVM进程，以后Twitter应该会开发更多的方式。

heron实例的配置也是同其他组件一样，可以调整topology生命周期的每个阶段。

5. Metrics Manager
每个topology都运行一个Metrics Manager(指标管理器，MM)，MM用来收集和导出容器内所有组件的指标。然后，路由这些指标到Togology Master(TM)和外部收集器，例如Scribe，Graphite，或者类似的系统。

Heron的其他组件
上面列出的5个基础组件是每个topology里面都有的，下面列出的组件是特定topology之外的一些组件。

1. Heron CLI
Heron有一个称为heron的CLI工具，它是用来管理topologies。比如可以用来提交、启动、或者删除一个topology。

2. Heron Tracker
Heron Tracker是一个中心化的网关，用来收集集群中运行的topologies所有运行信息，比如是否运行、是否部署、是否被kill掉了等等。它作为topologies的一个组件，是依附于集群中的Zookeeper节点上，并通过JSON REST API来公开信息。Tracker可以在Heron集群中运行，也可以在外部运行。

3. Heron UI
Heron UI就是一个可以和集群进行交互的可视化界面，它提供了完善和丰富的内容来监控和查看集群中的运行状况。

Topology Submit时序图

下面的时序图包含了用户在执行submit topology、deactivate topology、以及view topology时的时序结构


submit的详细提交流程：
Client

当使用heron submit命令提交一个topology的时候，首先会执行topology的main，创建一个包含topology逻辑计划的 .denf文件。然后会运行com.twitter.heron.scheduler.SubmitterMain，它会为topology调用加载器和launcher，加载器加载topology包到指定位置，launcher会注册topology的logical plan、State Manager的执行状态，以及调用main schedule。
Shared Service
当schedule的main函数（com.twitter.heron.schedule.SchedulerMain）被launcher调用的时候，它会从topology storage中获取提交的topology信息，初始化State Manager，并准备一个用来指定有多少个instance应该被打包进container的physical plan。然后，它会启动指定的schedule，比如 com.twitter.heron.scheduler.local.LocalScheduler，它会为每个container调用heron-executor。
Tolopogies

每个container启动的heron-executor进程负责执行被分配到该容器的Topology Master或者Heron 实例（spout/bolt）。需要注意的是，在container 0中Topology Master总是会被执行。在heron-executor执行正常的Heron实例（指除了container 0）时，它会为被分配到container中的每个instance启动（com.twitter.heron.instance.HeronInstance）之前准备好Stream Manager和Metrics Manager。

Heron Instance有两个线程，即gateway线程和slave线程。gateway线程主要是通过StreamManagerClient和MetricsManagerClient分别与StreamManager和MetricsManager进行通信，以及发送tuples到slave线程或者从slave线程接受tuples。slave线程基于physical plan来运行topology中的spout或者bolt。

当一个新的Heron实例启动时，它的StreamManagerClient会与StreamManager建立连接并进行注册，注册成功之后，gateway线程会发送physical plan给slave线程，然后执行相应分配的实例。