EasyScheduler设计围绕四个服务展开，UI、Web、Server和Alert。
@@ -820,7 +820,7 @@
1. 中心化思想
@@ -831,7 +831,7 @@中心化的设计理念比较简单，分布式集群中的节点按照角色分工，大体上分为两种角色：
-+
Master的角色主要负责任务分发并监督Slave的健康状态，可以动态的将任务均衡到Slave上，以致Slave节点不至于“忙死”或”闲死”的状态。
Worker的角色主要负责任务的执行工作并维护和Master的心跳，以便Master可以分配任务给Slave。
-+
去中心化设计里，通常没有Master/Slave的概念，所有的角色都是一样的，地位是平等的，全球互联网就是一个典型的去中心化的分布式系统，联网的任意节点设备down机，都只会影响很小范围的功能。
去中心化设计的核心设计在于整个分布式系统中不存在一个区别于其他节点的”管理者”，因此不存在单点故障问题。但由于不存在” 管理者”节点所以每个节点都需要跟其他节点通信才得到必须要的机器信息，而分布式系统通信的不可靠行，则大大增加了上述功能的实现难度。
实际上，真正去中心化的分布式系统并不多见。反而动态中心化分布式系统正在不断涌出。在这种架构下，集群中的管理者是被动态选择出来的，而不是预置的，并且集群在发生故障的时候，集群的节点会自发的举行"会议"选举新的"管理者"主持工作。最典型的案例就是ZooKeeper及Go语言实现的Etcd。
@@ -844,11 +844,11 @@EasyScheduler使用Zookeeper分布式锁来实现同一时刻只有一台Master执行Scheduler，或者只有一台Worker执行任务的提交。
1. 获取分布式锁的核心流程算法如下：
-+
2. EasyScheduler中Scheduler线程分布式锁实现流程图：
-+
线程不足循环等待问题
@@ -856,7 +856,7 @@
@@ -932,7 +932,7 @@如果一个大的DAG中嵌套了很多子流程，如下图：
-@@ -884,13 +884,13 @@+
则会产生“死等”状态。MainFlowThread等待SubFlowThread1结束，SubFlowThread1等待SubFlowThread2结束，SubFlowThread2等待SubFlowThread3结束，而SubFlowThread3等待线程池有新线程，则整个DAG流程不能结束，从而其中的线程也不能释放。
这样就形成的子父流程循环等待的状态。此时除非启动新的Master来增加线程来打破这样的”僵局”，否则调度集群将不能再使用。
EasyScheduler容错设计依赖于Zookeeper的Watcher机制，实现原理如图：
-+
Master监控其他Master和Worker的目录，如果监听到remove事件，则会根据具体的业务逻辑进行流程实例容错或者任务实例容错。
- @@ -898,7 +898,7 @@
Master容错流程图：
-+
ZooKeeper Master容错完成之后则重新由EasyScheduler中Scheduler线程调度，遍历 DAG 找到”正在运行”和“提交成功”的任务，对”正在运行”的任务监控其任务实例的状态，对”提交成功”的任务需要判断Task Queue中是否已经存在，如果存在则同样监控任务实例的状态，如果不存在则重新提交任务实例。
- @@ -921,7 +921,7 @@
Worker容错流程图：
-+
Master Scheduler线程一旦发现任务实例为” 需要容错”状态，则接管任务并进行重新提交。
介于考虑到尽可能的EasyScheduler的轻量级性，所以选择了gRPC实现远程访问日志信息。
-+
- @@ -940,7 +940,7 @@
FileAppender实现如下：
-+
以…/流程定义id/流程实例id/任务实例id.log的形式生成日志。
过滤匹配以TaskLogInfo开始的线程名称：
-+
