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 操作
閱讀代碼不是為了簡單的分析，是希望通過開源代碼了解實際業務邏輯是怎么轉換成代碼的，並開拓自己的架構視野。我們不需要扯淡，只要實戰。