共计 3614 个字符，预计需要花费 10 分钟才能阅读完成。
本节开始将对 Yarn 中的 NodeManager 服务进行分析。
NodeManager 须要在每个计算节点上运行，与 ResourceManager 和 ApplicationMaster 进行交互。治理节点的计算资源以及调度容器。后续将对 NM 的性能职责、状态机、容器生命周期和资源隔离等方面进行解说。本篇将从整体上对 NM 进行介绍。
一、NodeManager 根本职能
在 Hadoop 集群中，每个计算节点都须要有一个治理服务，其就是 NodeManager（NM）。
它负责与 ResourceManager 放弃通信，治理 Container 的生命周期，监控每个 Container 的资源应用状况，追踪节点健康状况，治理日志等。
主要职责：
- 放弃与 ResourceManager 同步
- 跟踪节点的健康状况
- 治理节点各个 Container 的生命周期，监控每个 Container 的资源应用状况
- 治理分布式缓存（对 Container 所需的 Jar，库文件的本地文件系统缓存）
- 治理各个 Container 生成日志
整体来说，NM 通过两个 RPC 协定与 RM 和 AM 交互，如下图所示。
一）与 RM 交互
通过 ResourceTrackerProtocol 协定：
- NM 通过该 RPC 协定向 RM 注册、汇报节点健康状况和 Container 运行状态；
- 支付 RM 下达的命令，包含从新初始化、清理 Container 占用资源等。
在该协定中，RM 表演 RPC server 的角色，而 NM 表演 RPC Client 的角色（由外部组件 NodeStatusUpdater 实现）。NM 与 RM 之间采纳「pull 模型」，NM 总是周期性地被动向 RM 发动申请，并支付下达给本人的命令。
二）与 AM 交互
通过 ContainerManagementProtocol 协定：
- 应用程序的 AM 通过该 RPC 协定向 NM 发动 Container 的相干操作（启动、kill、获取 Container 执行状态等）。
在该协定中，AM 表演 RPC Client 的角色，而 NM 表演 RPC Server 的角色（由外部组件 ContainerManager 实现）。NM 与 AM 之间采纳「push 模型」，AM 能够将 Container 相干操作的第一工夫通知 NM，相比于「pull 模型」，能够大大降低时间延迟。
二、NodeManager 内部结构
NodeManager 外部由多个组件形成，如下图所示。其中最次要的三个组件是：NodeStatusUpdater、ContainerManager、NodeHealthCheckService。
一）NodeStatusUpdater
NodeStatusUpdater 是 NM 与 RM 通信的惟一通道。
- 当 NM 启动时，该组件负责向 RM 注册，并汇报节点上总的可用资源；
- 之后，该组件周期性与 RM 通信，汇报各个 Container 的状态更新（包含节点上正在运行的 Container、曾经实现的 Container 等信息）；
- 同时 RM 会返回待清理的 Container 列表、待清理的应用程序列表、诊断信息、各种 Token 等信息。
二）ContainerManager
ContainerManager 是 NM 中最外围的组件之一，它由多个子组件组成，每个子组件负责一部分性能，协同治理运行在该节点上的所有 Container，各个子组件如下。
- RPC Server： 该 RPC Server 实现了
ContainerManagementProtocol协定，是 AM 与 NM 通信的惟一通道。ContainerManager 从各个 AM 上接管 RPC 申请以启动新的 Container 或者 进行正在运行的 Container。须要留神的是，任何 Container 操作均会经ContainerTokenSecretManager合法性验证，以避免伪造启动或进行 Container 的命令。 - ResourceLocalizationService： 负责 Container 所需资源的本地化，它可能依照形容从 HDFS 上下载 Container 所需的文件资源，并尽量将它们摊派到各个磁盘上以防止出现热点拜访。此外，它会为下载的文件增加访问控制限度，并为之施加适合的磁盘空间应用份额。
- ContianersLauncher： 保护了一个线程池以并行实现 Container 相干操作，比方启动或者杀死 Container，其中启动 Container 申请是由 AM 发动的，而杀死 Container 申请则可能来自 AM 或者 RM。
- AuxService：NodeManager 容许用户通过配置从属服务的形式扩大本人的性能，这使得每个节点能够定制一些特定框架的服务。从属服务须要在 NodeManager 启动之前配置好，并由 NodeManager 对立启动与敞开。
- ContainersMonitor：ContainersMonitor 负责监控 Container 的资源使用量，为了实现资源隔离和偏心共享，RM 为每个 Container 调配了一定量的资源。而 ContainersMonitor 周期性探测它在运行过程中的资源利用量，一旦产生 Container 超出了它的容许应用份额上线，就向 Container 发送信号将其杀掉，这能够防止资源密集型的 Container 影响同节点上其余正在运行的 Container。
- LogHandler： 一个可插拔组件，用户可通过它管制 Container 日志的保留形式，即是写到本地磁盘上还是将其打包后上传到一个文件系统中。
- ContainerEventDispatcher：Container 事件调度器，负责将 ContainerEvent 类型的事件调度给对应 Container 的状态机 ContainerImpl。
- ApplicationEventDispatcher：Application 事件调度器，负责将 ApplicationEvent 类型的事件调度给对应 Application 的状态机 ApplicationImpl。
三）NodeHealthCheckerService
NodeHealthCheckerService 通过周期性地运行一个自定义脚本（由组件 NodeHealthScriptRunner 实现）和向磁盘写文件（由服务 LocalDirsHandlerService 实现）查看节点的健康状况。
并通过 NodeStatusUpdater 传递给 ResourceManager。一旦 ResourceManager 发现一个节点处于不衰弱状态，则会将它退出黑名单，尔后不再应用该资源，直到再次转为衰弱状态。须要留神的是，节点被退出黑名单时，正在运行的 Container 仍会失常运行，不会被杀死。
四）DeletionService
NodeManager 应用一个专门的服务用于文件删除。异步地删除生效文件，这样可防止删除文件带来的性能开销。
五）Security
平安局部。它蕴含两局部，别离是 ApplicationACLsManager 和 ContainerTokenSecretManager，ApplicationACLsManager 确保拜访 NodeManager 的用户是非法的，ContainerTokenSecretManager 确保用户申请的资源被 ResourceManager 受权过。
- ApplicationACLsManager：NodeManager 须要为所有面向用户的 API 提供安全检查，如在 Web UI 上只能将 Container 日志显示给受权用户。该组件为每个应用程序保护了一个 ACL 列表，一旦收到相似申请后会利用该列表对其进行验证。
- ContainerTokenSecretManager： 查看收到的各种拜访申请的合法性，确保这些申请操作已被 ResourceManager 受权。
六）WebServer
通过 Web 界面向用户展现该节点上所有利用程序运行状态、Container 列表、节点健康状况和 Container 产生的日志等信息。
七）ContainerExecutor
与底层操作系统交互，平安的搁置 Container 所须要的文件和目录，随后以一个平安的形式启动和清理 Container 相干过程。
三、NodeManager 的事件与事件处理器
NodeManager 次要组件也是通过事件进行交互的，这使得组件可能异步并发实现各种性能。如下图所示：
四、总结
本节对 NodeManager 整体构造进行了介绍。从它的根本职能、内部结构、事件处理三个方面进行解说，对 NM 整体构造有了认知。
实际上 NM 次要就负责两个事件：1）与 RM 交互，注册以及汇报状态，支付 RM 指令解决 container。2）与 AM 交互，解决其治理的 container 操作。
参考文章：
《Hadoop 技术底细：深刻解析 YARN 架构设计与实现原理》
深刻 YARN 系列 3：分析 NodeManager 架构，组件与生产利用
NodeManager 具体组件及性能
Yarn NodeManager 总体架构
