Ambari窥探分布式心跳机制

Posted 2020-09-06

    Ambari是在Hadoop大数据生态圈的基础上应运而生，Ambari的架构也借助了分布式的思想，细细品味，与Hadoop分布式架构有很多相似之处。

    Hadoop中单NN 与多DN的通信是借助netty封装的RPC机制实现，单Ambari server与多Agent通信则是基于restful api + json实现，rpc与rest api的争论不是本文要讨论的重点，我们追求的目标只有一个，完美实现业务需求。

   心跳设计一个主要的原因是判断客户端是否在线，每隔一段时间会发送数据交互。Ambari agent是无状态存在，通过心跳机制定期发送数据，状态信息存储在server数据库中，并在ambari-web页面正确显示存活状态。Agent主要任务是负责收集每个节点本身信息以及各服务组件 status；接收server传达command指令并对组件等进行启停操作，语言的选择上python是首选。

    Ambari server不能主动给agent发心跳，只能通过agent的心跳请求返回信息中加入command queue以及对agent所要下达的其他一些指令，例如重新注册心跳、发送 status状态。接下来带你走进心跳机制实现的分布式架构：

接下来，简单明了，四个类带你了解Ambari心跳机制：

Agent端：两个线程类Control.py 以及ActionQueue.py

Control.py ：

init方法初始化以下两个接口，https安全接口后续文章结合openssl再详细分析

 

start方法后，执行run方法，开启while true循环，调用 registerAndHeartbeat（）

且先看注册方法：Register 相当于一个bean类，定义了rest请求需求注册的节点信息，server端有同样对应的一个Register类来接收，符合json与bean严格对应；注册成功后返回Response中会带有statuscommand指令，要求agent去收集各组件服务的状态信息，加入actionQueue队列中线程执行

 

 

注册成功后，则不会再进行该注册方法。

心跳方法同样有与server一一对应的HeartBeat bean类，会包含两类信息，上一command 执行结果result以及各服务状态信息。以下方法是对每次心跳返回response信息进行下一步处理，例如执行启停某一服务组件等。

Server端：

AgentResource.java  以及HeartBeatHandler.java

@Path("register/{hostName}")，该接口用于接收register请求，handleRegistration（message），返回RegistrationResponse，也就是agent端注册请求后的response信息

@Path("heartbeat/{hostName}")  ，该接口用于处理心跳，handleHeartBeat(message)，返回HeartBeatResponse，该信息也就是上图中的response。

Server通过以下三个循环做心跳处理(处理过程通过事件驱动以及fsm状态机去实现)

 

 

总结：Agent两个线程，control负责发送注册（注册信息就是hostname以及一些节点机器硬件信息）、心跳（status以及command result）请求；ActionQueue负责执行command （执行server需要agent的操作）

server ：接收注册信息，触发事件驱动由FSM去更改状态数据库，之后返回StatusCommands请求；

心跳接口 接收前一指令的result status，触发各种事件驱动更改数据库；返回web操作的command 操作

 

    阅读代码不是为了简单的分析，是希望通过开源代码了解实际业务逻辑是怎么转换成代码的，并开拓自己的架构视野。我们不需要扯淡，只要实战。