DophinScheduler server部分 核心代码详细解析——掌控任务和进程的呼吸与脉搏：log、monitor与registry

2021SC@SDUSC

---

一、整体结构

前文链接：DophinScheduler server部分 核心代码详细解析——DophinScheduler至关重要的角色Master在server在承担了何种功能？

log、monitor、registry分别建立了3个各自不同的文件夹，其对应的功能分别为掌管进程中各种操作与指令日志的纪录、检测并调控任务进程的运行状态、注册各种用到的进程，为它们登记。
这三者共同作用，相辅相成，携手掌控DophinScheduler server部分任务执行和分配的流程和运行状况，调整任务执行节奏，把控进程呼吸，在任务的分配和执行过程中起到了至关重要的作用。也正因如此，我们将为它们单立一篇博客集中分析。

二、具体分析

1.log

我们可以看到，该目录下的java类主要分为logger本身的请求处理进程与logger服务器，以及对于任务细分的logger。

1.LoggerRequestProcessor

现在我们来看看第一个类，LoggerRequestProcessor。
图中所示为这个类的核心代码，主方法process。
方法中，开头调用logger类的info方法向日志中记录操作指令，随后根据指令类型的不同用switch语句细分了4种情况，分别对应获取日志字节请求、浏览整个日志请求、滚动浏览日志请求和溢出任务日志请求。
这些方法的共同点在于调用channel类的writeAndFlush方法，将日志命令写入并转化为日志请求，然后刷新命令池。

2.LoggerServer

这个类的主要方法是配置服务器设置，然后注册用到的各种类型的进程并启动整个logger服务器进程。

3.MasterLogFilter

可以看到这是管理者进程日志的分类器，类中主方法是decide，用来决定一个管理者进程的日志应当被记录还是拒绝，并提供设置日志等级的功能。

log目录下其他类的逻辑都与我们上述的代码相似，功能上的差异主要在于应对各种各样不同的情况，核心代码中没有什么特别值得注意的点，因此对于log的分析到此为止。

2.monitor

可以看到，monitor目录下写了monitor抽象类以及接口，但目前真正实现的只有RegistryMonitor。预留的接口和抽象类为以后扩展功能提供了便利，这一点充分体现了软件工程的代码编写规范，值得我们学习。

1.RegistryMonitor

现在我们来看一眼RegistryMonitor都在做些什么：

正如第一行注释所揭示的那样，DophinScheduler是借用了zookeeper提供的服务的。
主方法返回一个protected的Map类型对象，方法内部所做的事便是获取注册用户进程的孩子名单，对其进行一定的处理后加入Map映射并返回。
根据这里的处理方法：child.split("")推测zookeeper中分隔孩子进程用的是""，且不存在其余多余字符。

2.RunConfig

可以看到这个类中大部分方法都是get和set，没有什么实质性的内容。
但我们应当注意到他对于Masters和tWorkers的处理。monitor主要的任务便是监测并调整这两个身份的进程的运行状态。
另外比较有意思的便是getWorkers方法中，设立了一个StringBuilder对象，而在侯旭东处理中，从workerGroup中提取workers到workersArr的方法用的是.split(Constants.COLON)，也就是通过字符串的处理来区分。
通过对这个Constants.COLON的来源追查，我发现它是dolphinscheduler在common.Constants中定义的常量，赋值为’:’，也就是说这里就相当于’:’。但以这种方式命名同样符合软工编写标准，后续如果想要更改分隔符可以简单地在源头处更改便可全部更改，不仅省时省力还能保证代码的一致性。

3.registry

这个目录的构成比较简单，只有一个HeartBeatTask类，用来掌控任务心跳。

显然，这个类继承自Runnable，主要方法也就是run()来启动这个进程了。对于run方法的细节我们并没有太大的兴趣，倒不如来看看心跳进程都记录了些什么信息。
可以看到，开头就声明了起始时间startTime、CPU最大负载的平均值maxCpuloadAvg、预留内存大小reservedMemory、我们之前博客提到的host权重hostWeight、心拍路径heartBeatPaths、服务器类型serverType，还有注册用户registryClient。除开意料之中的业务相关的信息，CPU负载和预留内存这两项比较有意思。心拍进程要预分配和调度时间的物理硬件的使用情况，很有意思。
既然叫做心拍进程，不应该和调节进程节奏关系更大么？分配物理硬件的事为什么会让它来干呢？
这处细节笔者虽发现了，但暂时没有能力解释。在后续的学习和研读代码中如若明白了代码编写者的用意，笔者将单独立一篇博客具体分析，并回到这篇博客中将这部分进行简单完善。

对于掌控着任务和进程的呼吸和脉搏的log、monitor与registry部分的分析到此就结束了。