以下内容转自网络
来源：公众号"taskctl"
1.前言
批量处理是银行业整个信息后台最为重要的技术形态，也是银行核心信息资产数据的分享、传输、演化的重要技术手段。有调查指出，全球70%的数据是经过批量处理得以再次使用，可见批量处理在整个信息生态中的技术占比与重要性。
银行业经过多年的信息化建设，逐步建立起几十甚至几百个信息系统，其中，绝大多数系统后台都具备有不同规模的作业批量处理，总体批量作业数已发展成几千到几万这样的一个庞大规模。随着大数据时代的到来，特别是在数据仓库、大数据平台的带动下，这样的规模还将快速发展，其批量作业数规模也必将产生数量级的增长变化。
银行面对如此多的系统、批量作业数以及可期的快速增长未来，让批量处理最为重要的技术-批量调度走向独立化、系统化、专业化以及平台化，是非常有必要的。批量调度不仅是批量处理的动力中枢，也是整个批量处理的管理入口，因此，建立一个规范专业的批量作业调度技术平台，建立一个统一的批量作业调度运维管理平台，不仅可以从架构层面优化企业整个后台批量体系，减少IT技术异构风险，为数据安全提供更可靠的技术保障，还可以加快具体系统构建速度，提升系统运维效率，降低运维风险。批量调度技术体系的专业化、平台化、统一化，不仅是一个系统建设，更是银行IT基础设施平台的建设，为银行整个IT建设健康高效发展提供坚实的基础。
2.批量调度现状分析
2.1.目前主要实现方式
目前，由于银行内部缺乏一款专业批量产品支撑，缺乏一定的批量调度规范与标准，使银行内部几十上百个系统相关批量调度实时混乱。这种现象不仅体现在银行不同系统之间，甚至体现在同一系统的不同建设周期之间。
2.1.1.应用系统内置，手工调度调度
目前，在银行内有很多系统的后台批量处理，无论从后台调度层面，还是前台应用层面，都与业务系统本身高度耦合，而且调度触发启动主要是靠人工发起。造成这种局面的原因一方面是银行缺乏统一的调度规范体系，另一方面，站在整个应用系统的角度，批量调度本身比重不大。
这种方案带来的直接后果体现在两个方面：一是因高度耦合，扩展不易；二是主要靠人工调度，相对较耗人力资源，而且因人工操作，可能会引入更多人为误操作的风险。
2.1.2.采用操作系统Crontab方式调度
这种方式主要是依靠操作系统的定时机制，实现作业运行的自动化。这种方式容易引起依赖关系错误对业务构成威胁。同时，无法实现作业容错机制，在运行过程，一旦发生作业错误，需大量的人工介入处理。
2.1.3.项目组自行开发调度软件
该方案主要根据项目具体的需求以及结合调度的规模，设计并实施不同程度的调度。对于小规模的系统，通常编写简单的shell即可实时调度，弱化调度的管理性、监控性等潜在需求；对于规模较大的系统，实施者通常站在整个项目的高度，综合分析项目的各种调度需求，通过一系列分析设计，构建一个相对规模的调度系统，并建立与之匹配的监控管理等应用系统。
此方案可由项目自由实施，可客户化一些具有项目特色调度管理系统，与项目现有情况结合比较密切。但是，这种方案容易受项目的局限，系统扩展也非常困难。
2.1.4.利用现有ETL工具的调度功能
随着银行信息化发展，特别是数据仓库的建立，并以此为基础建立的更多数据类、管理类系统，或多或少都在采用一些专业的ETL工具来实现批量处理，并结合工具本身的调度组件完成相应批量调度处理工作。
工具举例如下：
1、Datastage工具：我们采用其sequrence job实现流程开发，通过对sequrencejob执行，从而完成调度。
2、Informatic工具：我们采用其workflow实现流程开发，通过对workflow的执行，从而完成调度。
3、Kettle工具：我们采用其kjb实现流程的开发，通过对kjb的执行，从而完成调度。
2.2.批量调度现状统计
2.3.批量调度现状主要问题
根据以上对银行批量现状的列举分析，其问题主要体现在以下三个方面：
问题一：批量调度建设杂乱
调度方式众多，手工调度、操作系统定时、应用系统内置、多种独立调度系统、多种第三方工具等，由于缺乏具体的标准，当数量与规模发展到一定程度，无论是管理与扩展都比较难。
问题二：实施及运维管理较难
方式多，功能不统一，信息不统一，管理孤立于各个系统，专业度参差不齐，技能难以复制。这造项目中不断重复建设、技术不断重复学习，管理难以统一协调。总之，没有专业统一的技术，无论是项目实施建设，还是具体生产运维管理，相应工作的开展都非常困难。
问题三：技术与管理潜在风险较大
风险主要体现在两方面：一是技术带来的稳定性风险，由于缺乏统一专业的技术支撑，任由各个系统自由无序的建设，站在全行的角度，调度的稳定性是难有技术保障的。另一方面，缺乏统一的应用接口，统一的操作界面，使运维管理缺乏统一的操作流程，站在全行的角度，整个批量管理是无序的，其管理风险一定会随着银行批量规模的增大而增大。
2.4.面临的未来挑战
缺乏统一专业的批量调度平台，随着银行的IT深入发展，即将面临两大挑战：
挑战一：难以完整实现银行企业级统一运维管理平台建设
银行众多的系统以及庞大的IT设施，为了保障全行IT的高效稳定的运转，从各个纬度逐步建设统一的综合运维管理平台是个不可逆转的大趋势。而对决定银行70%的数据运行与变化的批量调度的统一监控管理，一定是必不可少的重要组成部分。然而，对批量调度而言，建设统一监控管理平台，没有统一专业的调度技术平台做支撑，是难以实现的。
挑战二：难以支撑未来大数据的批量作业常态化、规模化发展
在IT时代，虽然银行后台批量处理规模已经很大，但相对于银行整体IT系统建设而言，其规模与比重还不大，建设频度也不高。然而，对于已经开启的大数据时代、DT时代，在一切以数据为驱动的建设模式下，数据整合是常态、批量处理是常态、批量调度是常态。可以说，有数据地方就离不开批量，而且，未来批量无论从数量还是规模比重，都不是过去可比拟的，如果缺乏专业统一的调度技术，是很难支撑未来常态化、规模化的批量发展，很难支撑未来更多以数据整合为基础的应用创新。
3.批量调度统一建设目标与意义
3.1.批量调度统一平台的两大建设目标
批量调度技术像任何基础技术平台、中间件技术平台一样，首先基于流程化、自动化的作业调度技术问题，其次是对该技术应用、管理以及技术应用的监控问题。我们对批量调度统一平台的建设目标也是以这两个问题的确立的，分别是批量调度技术统一工具平台，其次是批量调度统一监控管理平台。
● 目标一：批量调度统一技术工具平台：技术工具平台主要为各个系统提供批量调度流程化、自动化的调度技术服务。其主要使用用户为系统实施、改造的技术人员。在项目实施过程当中，通过专业的技术平台，使技术人员更快捷、更专业、更灵活、更规范地完成各个系统具体批量作业调度需求。
● 目标二：批量调度统一监控管理平台：监控管理平台主要为系统运维管理人员提供平台化服务。通过统一视图、统一监控、统一预警以及更多的分析管理功能，使运维人员可以快捷、高效地完成对各个系统批量处理的维护、监控、管理等工作，可以更为有效地确保全行批量后台的整体运行。
● 两者关系：技术工具平台偏向技术应用，监控管理平台偏向管理应用。监控管理平台是技术平台的更高层次的应用延展，也是整个批量处理的更高层次的应用诉求；而技术平台的专业化、统一化，是统一监控平台得以实现的基础。
3.2.两大目标的具体意义与价值
总的意义与价值：进一步完善银行后台IT技术基础设施，为未来更多的IT建设与应用创新奠定坚实的基础。
3.2.1.批量调度技术统一工具平台意义
建立一款具有统一技术与规范的调度技术工具平台，对银行整体统一批量调度建设，具有以下五点意义：
（一）建立专业统一的批量作业调度技术平台，是建立批量作业调度统一监控的基础。
由于技术原因、历史原因，目前银行批量调度技术缺乏一定的规范与标准，很难提供统一接口，并在此基础上建立一个统一监控平台。只有一个专业、完善、统一的技术平台，才可以建立一个完善的统一监控平台。
（二）建立专业统一的批量作业调度技术平台，为企业建立批量后台统一驱动中枢
数据是企业的资产，批量系统是整合数据的重要支撑，而调度则是批量的灵魂，企业所有的批量整合数据都靠调度来驱动。建立一套统一、专业且功能完善的技术平台，可以为银行70%的数据运行的安全性、可靠性提供更高的技术保障。
（三）建立专业统一的批量作业调度技术平台，提升各个应用系统的实施效率
银行诸多系统的升级、改造、重构以及新建，都离不开批量调度的建设与应用。一套具有统一规范、功能完整、安全可靠的批量调度技术平台，不仅可以减少项目实施的工作量，提升各个应用系统的实施效率，还可以大幅度提高各个系统批量处理的实施质量。
（四）建立专业统一的批量作业调度技术平台，提升企业整个后台批量处理效率
银行后台批量整体效率，直接决定银行对客户服务效率与质量。而银行大部分批量处理都存在上下游关系，由于目前缺乏统一专业的调度技术，很难统一协调上下游批量处理关系，从而造成了一定批量时间窗口浪费。建立一套具备灵活的系统间触发机制的统一调度技术平台，可以有效编排不同系统批量处理的时间窗口，并大幅度提升银行后台整体批量调度效率。
（五）建立专业统一的批量作业调度技术平台，减少人工操作，提高生产力，保障数据运行安全
由于缺乏一个专业易用的调度技术平台，目前银行很多系统调度都采用人工操作，这不仅浪费人力，同时，因人为操作因误操作、漏操作，均带来一定的潜在风险。建立一套以自动化技术为核心的批量作业调度技术平台，不仅减少人工操作，提高生产力，还降低大量的人为风险，进一步保障数据运行安全。
3.2.2.批量调度统一监控管理平台意义
在各系统统一批量调度技术工具平台基础上，建立银行批量调度统一监控运维管理平台，对银行整体统一批量调度建设，具有以下三点意义：
（一）建立统一的批量作业调度监控管理平台，是银行后台综合统一运维管理平台不可或缺的重要一环
为保障银行庞大的IT设施环境运行，从各个纬度建立一个统一的监控体系，建立一个完善统一的监控运维平台，是银行IT发展的必然趋势，而其中对批量调度的统一监控，可以说是最为重要的一环。数据作为银行的核心资产，其中70%以上是通过批量调度运行得到，为了保障银行70%的数据运行稳定与安全，建立一套行之有效的统一批量调度监控平台，是非常有必要的。
（二）建立统一的批量作业调度监控管理平台，提升运维管理效率，降低运维管理风险。
企业后台运维，很大一部分工作是与批量相关、与批量调度相关。将分散到各个系统的运维管理应用，集中到一个统一平台，进行统一展示、统一监控并提供统一的操作运维窗口，不仅可以成倍提高运维管理效率，还可以加快问题处理响应速度，从而降低运维管理风险。
（三）建立统一的批量作业调度监控管理平台，增强批量作业调度情况的可分析能力。
通过统一的批量作业调度监控管理平台的建设，可以将企业各系统的批量调度处理相关数据信息，完整地集中到一个统一平台，为开展各种调度以及作业处理的分析，奠定坚实的技术基础。
4.建设过程中关键点与主要问题
批量调度是一个与业务无关的纯技术应用体系，同时，业界也有相应发展多年的技术产品，并积累了一定的技术经验。但站在银行的角度，面临如此多的应用系统以及各种复杂的技术应用场景，要想建立一个适应银行各个系统应用，并可实现全行统一监控的有效批量调度应用体系，在现有的诸多技术经验基础上，还得解决以下几个关键问题：
（一）调度技术体系与统一监控管理体系的分离
目前，诸多的批量调度解决方案，批量调度与监控应用管理，高度耦合，使统一监控与各系统的独立调度难以拆分，使每个系统的调度应用难以独立开展，进而阻碍了全行更多系统的推广应用。唯有将调度技术体系与监控管理体系的彻底分离，才可保证各个项目在统一技术标准的基础上独立使用，并在完全保证各系统的独立自主的基础上，实现全行级统一监控管理。
（二）以流程图为核心的可视化实用性要求
系统应用可视化，是决定批量调度应用成功与否的关键，而流程图的可视化是整个批量调度应用可视化的核心，因为，批量调度的技术核心就是围绕着成千上万作业有序化运行展开的。但目前绝大数方案当作业数上升到一定量级，作业关系展示就非常凌乱，失去可视化的实用性。怎样使成千上万作业的主要序列关系清晰展示，也是本课题的关键问题之一。
（三）作业流程设计的专业化工具平台
在统一规范的技术平台技术上，每个系统根据自身批量作业调度需求，设计每个系统独自的作业调度流，是银行整个批量系统应用的关键应用场景。设计一个专业易用的作业调度流设计平台，可以大幅度提升每个系统具体实施时的用户体验，可以大幅度降低诸多系统的推广应用成本。
（四）作业类型支持的统一性与可扩展性
银行现有批量作业类型非常复杂，有各种技术平台脚本、SQL、存储过程以及各种ETL工具的作业，未来，还不可避免引入更多新的技术平台来完成各种批量作业。为了保证对各种作业类型的调度驱动，必须建立一套具有统一接口并开放的的作业驱动模式，才可保证调度平台的长期推广应用。
5、方案介绍
5.1.总体方案
5.1.1.方案总体架构
方案总体架构
整个方案通过在每个系统独立部署调度技术平台，并实施每个系统独立批量调度控制需求。在此基础上，全统一部署一套批量调度监控平台，以实现全行级统一批量调度监控管理需求。
监控管理平台与分布在各个系统上的调度技术平台通过tcpip方式信息，向上实现从技术平台到管理平台的调度相关数据的实时同步，向下实现从管理平台到技术平台的各个人工操作控制指令。
监控平台采用基于web的bs模式实现各种应用。技术平台服务是由纯C语言的服务程序构成，而且技术平台可以通过标准客户端，并以CS模式连接，实现对每个技术平台的独立应用。
5.1.2.方案总体特征
整个方案具有两个重要特征：
低耦合：独立调度、统一监控
系统采用独立调度、统一监控的架构设计，彻底解除底层自动化调度技术与应用操作之间的偶；解除批量调度生产系统与系统监管平台之间的偶；解除不同系统之间自动化调度技术的偶，既可实现每个系统调度自动化的独立自主应用需求，又可实现全行几十上百个系统的批量调度统一监控、统一视图、统一管理等需求。
多渠道：字符、命令行、桌面图形、BS多种应用客户端
整个平台解决方案，为了满足不同应用场景、不同角色的应用需求，分别设计多种渠道应用客户端。首先从整体平台体系结构上，分别具有BS应用体系与CS应用体系。BS模式是站在统一运维监控的角度应用。而CS模式完全站在技术平台，独立项目的角度应用。同时，对于CS模式还具有更精细的渠道应用设计，不仅将系统应用功能按应用类型通过Admin、Designer、Monitor三个软件来组织与应用，同时又按不同应用渠道分前台桌面客户端与后台字符界面客户端，它们分别构成完整的应用系统。用户可以根据自己的操作习惯与具体应用环境，选择合适的客户端渠道进行应用操作。
5.2.调度技术工具平台
5.2.1.技术平台总体架构
技术总体架构
整个技术平台采用典型的CS模式，应用层为客户端，控制层为服务端。同时，服务端完成对目标层的调度控制。
● 应用层：应用层从功能的角度，主要分admin，designer,monitor。从应用渠道的角度，又分桌面客户端渠道与后台字符界面客户端渠道。同时，为了进一步方便用户，系统服务端还提供了丰富的控制操作行命令。
● 控制层：控制层是多级金字塔架构，顶层为服务控制节点，完成各种调度服务控制以及为客户端提供各种操作应用服务。而代理层代理层完成与目标服务器（ETL等）的控制交互。另，代理层通过主从代理级联方式，可实现对集群部署的服务器进行调度控制，实现负载均衡等。
● 目标层：目标层是整个产品所控制的标的，比如我们的ETL服务器，作业工作站等。
通过应用层与控制层的结合，及标准的客户端与服务端，可以实现技术平台的独立完整使用。即可适应每个项目的独立调度使用，又可实现多个项目统一调度使用。
5.2.2.技术平台核心逻辑架构
技术平台核心逻辑
产品核心是在自主创新核心技术：无数据库存储访问、全事件组件间通信触发（消息队列）、动态数据全内存访问的基础上构建的。
在整个逻辑架构中，每一个组件对应一个系统进程，整个核心功能就是由不同功能的进程有序协同完成。
具体核心组件说明：
组件说明
5.2.3.技术平台多种应用部署解决方案
5.2.3.1.普通单项目应用部署方案
单项目应用部署方案
该部署方案是绝大数系统批量调度应用的部署方案。其特征是无需独立服务器，只需在具体应用系统的批量或相应ETL服务器上部署技术平台Server即可。
用户可以直接通过技术平台标准客户端（图形客户端、字符界面客户端）操作管理对应的调度系统。
5.2.3.2.多ETL服务器项目群部署方案
多ETL服务器项目群部署方案
该部署方案主要针对具有多个批量处理服务器或多个ETL服务器的应用系统。在具体部署时，首先需要部署一个独立技术平台Server，并在多个具体的批量或ETL服务器上部署技术平台核心代理Agent组件，通过Server与Agent之间通信实现对具批量或ETL服务器部署的作业的调度。
用户可以直接通过技术平台标准客户端（图形客户端、字符界面客户端）操作管理，并实现调度管理，以及各个ETL服务器上作业的运行监控。
5.2.3.3.简易企业级多项目统一调度、统一管理部署方案
统一管理部署方案
该方案部署本质是与多ETL服务器项目群部署一致。同样是独立部署技术平台Server，在不同系统的具体批量服务器上部署代理。Server通过agent实现各个系统的具体作业的调度控制处理。
这种方案是一种简易的企业级多项目统一调度、统一监控、统一展示、统一管理方案。
该方案主要优点是可以简单快捷实现多项目企业级统一调度管理，其缺点一是每个项目不能独立自主，受制于统一的调度服务器，第二是应用管理功能相对较弱，一些客户化应用功能难以实现；
5.2.4.技术平台特征优势
TASKCTL调度技术平台不仅仅强调能完成各种不同的调度处理等核心功能，更强调用户怎么使用调度等友好的用户体验，整个产品设计概念创新、亮点众多、优势突出。
高可靠：全方位的高可靠技术平台
系统核心技术平台，调度服务器与执行代理，分别采用主备机制与集群机制，可实现从调度服务器到代理的全方位高可靠，从而解决整个核心的单点故障问题。服务主备保证服务体系的故障连续性，代理集群不仅解决代理到作业服务器的故障连续性，同时还实现作业服务器的负载均衡。
自主：唯一无数据库与第三方中间件
TASKCTL技术平台是全球整个业界唯一无数据库、第三方中间件的专业作业自动化技术平台。无论是数据存储、内存计算、消息通信都是独立自主研发完成。这种完全独立自主的研发，无疑使整个产品的设计难度成倍增长，但同时这种成倍的难度，也倒逼我们做更多的技术创新。
高效：调度性能数量及优势
无数据库、全内存计算、灵活的消息通信是我们高效的基础，这种不一样的技术基因促使我们的调度性能与诸多同类软件具备数量级优势。目前大部分同类产品的调度吞吐量为1个/秒，而我们调度可以轻松突破40个/秒。
节省：建设成本百万级节省
在传统观念中，银行全行级调度建设，无疑是一个高投入的项目，它的建设需要依赖更多的资源支撑，需要多个数据库服务器、调度服务器以及更多的第三方软件投入，这些依赖成本轻松突破百万。而TASKCTL解决方案，因建立在简洁高效的核心基础上，无需独立数据库服务器、高性能的调度服务器以及无需第三方软件等，这对大型调度建设方案来说，节约百万级的成本投入，是一件非常轻松的事。
可视化：可视化最彻底的流图
可视化的目的是直观，并在直观的基础上操作便捷。对于批量作业调度，可视化的核心无疑是对作业的展示、关系展示等。TASKCTL采用全新的信息组织模式，以及流程绘图的全新算法，具有‘全自动排版’、线条‘永无交叉’、关系‘永远清晰’等特征。相比传统交叉、排版不清具备明显的优势。
开放：公开透明的插件扩展
TASKCTL是一个开放的作业调度自动化技术平台，为了适应诸如Datastage、Informatica、kettle、一体机、大数据、存储过程、java以及各种脚本任务程序的支持与扩展，同时保证不同任务类型的应用统一，TASKCTL对任务的控制采用插件驱动机制，从而实现不同技术平台、不同任务类型统一调度控制以及统一应用。
友好：唯一IDE环境设计作业
一个调度系统，用户群角色较多，其技术开发人员可以说是主要使用人群，且作业设计也是一个最为重要的应用场景。传统诸多软件采用简单的对话框方式，无法满足实际应用诉求，迫使用户采用excel方式。而TASKCTL采用独特的理念，通过设计一个完整的IDE环境，用户可以通过该环境轻松实现作业的定义与设计，使整个系统应用变得更为友好。
简单：深入骨髓的极简主义
功能完整是基本，简单易用才是王道。TASKCTL一切站在用户的立场，从内核到应用均奉行极简主义，无论是无数据设计还是IDE设计，成倍的产品设计难度倒逼了我们更多的技术创新，这也是构建我们易用的基础，也是突破诸多应用场景易用性瓶颈的技术支撑。其中产品的5分钟内快速安装、调试、部署到位是整个业界绝无仅有的。
5.2.5.技术平台功能体系
功能体系
完整的核心调度功能
技术工具平台核心主要可以完成串行、并行、依赖、互斥、执行计划、定时、容错、循环、条件分支、远程、负载均衡、自定义条件等各种不同的核心调度功能。
直观的图形界面系统
根据不同的功能分类，技术工具平台将客户端分为Admin(平台管理)、Designer(流程集成开发环境)、Monitor(流程监控管理)三套不同的软件。
● Admin：平台节点管理、任务类型管理、工程管理、应用设置、全局变量管理以及流程导入导出等功能。
● Designer：平台流程代码信息管理、代码设计编辑、流程图形编辑、规则语法实时检测功能以及编译发布等功能。
● Monitor：图形方式监控、多角度统计监控、流程启停重置、任务锁定、任务重做、信息对象查询等
完整的字符界面系统
字符界面客户端系统与桌面图形软件对应，也分相应的三套软件完成对应的功能。字符界面系统相比桌面系统，直观性、可操作性相对弱些，但功能完整性比桌面系统更强
灵活的扩展功能
技术工具平台本身具备完善的调度、管理、监控等功能体系，是一个独立的应用平台，同时也是一个开放的平台，具备很强的扩展性。在技术上我们主要通过一系列核心接口函数实现扩展。
5.2.5.1.调度服务核心功能
核心调度功能是调度平台最核心、也是最基本功能，它决定了产品可以完成什么样的自动化调度。
● 串行调度 串行调度即依赖调度，依赖调度是调度软件最基本的功能，它决定任务之间的执行顺序关系。如果A任务依赖B任务，A任务必须让B任务执行成功可以执行A。
● 并行调度 并行调度也是调度最基本的功能，它表示并行任务之间可以同时运行。
● 互斥调度 互斥调度是指两个任务不可以同时执行，A与B互斥，A执行时B不能执行，B执行时A不能执行。
● 执行计划调度 执行计划指时间执行计划，这在ETL处理中是尤为重要的，比如任务按日执行、按周执行、按月执行都是属于执行计划。执行计划在ETL中，有两种方式，一种是按逻辑业务日期制定计划；一种是按自然日期制定计划。TASKCTL-CIR在一个流程可以同时支持两种计划的处理。
● 容错策略调度 错误任务自动处理是调度平台的一种容错机制。它决定调度后续方向；CIR对于错误的任务有两种处理机制，一是自动在一定时间间隔后重跑，当达到用户定义的最大重复次数时任务都未成功。表示所有依赖该任务的相关任务都不能处理；二是可以根据用户定义，选择在任务出错时忽略错误，流程继续往下运行。
● 断点续跑 断点续跑指流程因任务失败被迫中断时，经过人工处理后，流程会自动从中断的地方继续往下运行。
● 任务循环调度 循环调度是指在一个批次处理时，我们可以根据用户定义循环次数实现对某个任务循环调度。
● 条件分支调度 条件分支类似程序设计时，根据某个判断，决定执行哪个流程分支。
● 远程任务调度 远程任务调度是调度核心通过部署在远程代理对远程任务进行控制调度。它可以对部署在不同主机的任务通过统一流程进行统一管理并调度。
● 负载均衡调度 负载均衡指任务通过代理集群部署，调度可以分派任务到集群内相对空闲的主机，从而达到调度对流程负载均衡处理的功能。另外，调度是不能实现对同一个任务分派到不同主机执行的功能。任务是调度的最小力度单元。负载均衡只是站在整个流程的角度上考量的。通过调度的负载均衡部署，可以将多个并行任务分派到不同主机，避免在一台主机上同时并行执行多个任务，从而造成主机负载过重。
● 自定义条件调度 核心调度在技术上的本质，就是确定一个任务的执行条件。判断任务之间依赖并发等就是属于执行条件之一。其实，调度核心对任务的执行条件远非只有依赖并发这些条件，我们根据实际经验，归纳总结了很多条件，比如：执行计划、互斥、容错处理等均属于任务的执行条件，但是总结归纳是有限的，变化是无限的，在一些复杂情况下，总会存在一些不可确定的执行条件。为此，我们在众多可总结的条件基础上，增加了用户自定义条件接口，以满足不可确定的调度需求，从而也使CIR核心调度体系得以完善。
5.2.5.2.客户端应用功能
应用功能是建立在核心功能基础上，通过客户端工具软件来实现，它决定了用户怎么使用调度平台。
5.2.5.2.1.桌面系统与字符界面系统的关系与区别
桌面系统软件与字符界面系统软件均为调度平台独立应用体系，它们均从不同的用户对象以及不同的应用场景通过三套不同的软件实现。该三套软件分别为：
- l Admin 平台综合管理软件
- l Designer（后台为Flowc）流程设计管理软件
- l Monitor 调度监控管理软件
以上不同渠道的三套软件关系为：
另外，前后台均具有以上三套客户端软件，均为独立应用体系，但前后还是存在一定的区别，主要表现为：
（一）前台桌面软件比后台软件更直观
由于不同展示技术的原因，前台采用图形方式，而后台采用字符方式，因此在一些展示功能方面以及操作便捷方面，前台比后台更具优势。
（二）后台软件比前台桌面软件功能更全面
但如果只从功能角度，后台比前台更为全面，有些深层次的应用，前台可能不具有，但后台有相关的应用。
总之，前后台虽然都是独立的应用体系，但都存在不同的优劣势，应用者可以根据不同的应用场景选择不同的系统，或者两者配合使用，以快捷达到应用目的为宗旨。
5.2.5.2.2.图形客户端-Admin
该模块软件主要应用于系统初始化以及平台规划管理，其主要功能为包括：平台节点管理、任务类型管理、工程管理、应用设置、全局变量管理以及流程导入导出等。
（一）平台节点管理界面
该界面主要用于定义核心节点，即EM节点、Server调度服务节点以及代理节点与这些节点之间的关系。
（二）任务类型管理界面
通过该界面，用户可以定义自己的任务类型，包括该任务的类型名称、返回值定义、驱动插件程序名称、缺省参数、以及该类型在流程图中显示的图标等信息。
5.2.5.2.3.图形客户端- Designer
该软件主要应用于调度流程设计。该软件的设计打破了传统采用表单对话框或图形拖拽加属性对话框的方式。而是采用开发的理念，以面向用户具有一定语法规则文本代码为核心，并可同步实现图形配置的方式进行流程设计。用户可以结合自身对流程代码的理解深度以及操作习惯，既可以通过图形对话框的方式设计，又可以通过编辑性很强的文本代码方式进行设计开发。该方式杜绝传统借助诸如第三方Excel补充配置方案，使平台对流程的配置设计以及流程管理真正达到系统级的应用统一。
（一）流程集成开发环境主界面
（二）代码设计窗口
（三）流程图形编辑窗口
（四）执行计划编辑窗口
5.2.5.2.4.图形客户端- Monitor
该软件主要用于调度流程监控以及运行维护，其主要功能包括：图形监控、多角度统计监控、信息查询以及相关流程运维处理等。其中流程运维处理主要指流程启停、任务重跑等。
（一）监控平台软件主界面
（二）图形监控界面
（三）定时器监控界面
（四）作业列表统计监控操作界面
5.3.统一监控管理平台
批量调度统一监控管理，是完全站在银行运维监控的角度设计的应用平台。该平台的应用是以独立的调度技术平台为基础，并可实现多个技术平台，多个批量调度应用系统的统一监控运维管理。
5.3.1.统一监控平台总体架构
5.3.2.统一监控平台功能体系
5.3.2.1.首页-总览平台监控信息
该页从全局角度去展示当前调度作业的调度状态总体情况；分为4块展示：作业概况、作业排程、消息警告、节点信息；
作业概况：从不同作业运行状态统计数量，分别为作业成功、作业未运行、作业正在运行、作业警告、作业错误。
作业排程：统计当天不同时间段运行的作业数量。
消息警告：统计作业异常、平台异常、提醒、通知消息4个维度的异常数量；
节点信息：统计节点服务器的CPU运行消耗数据；
5.3.2.2.企业系统全局时间窗口
展示企业级内所有系统在当天调度监控内的时间运行范围。更直观地展示了系统运行窗口，促使能够合理地优化系统之间的调度时间安排；
5.3.2.3.图形监控
从不同角度模块、容器，监控当前作业运行状态统计的总体概览；并且支持对作业的执行操作，例如任务锁定、强制通过、运行任务等。
5.3.2.4.网络拓扑
监控各个节点的运行情况，列表展示当前网络内各个节点的节点信息：节点名称、节点IP、节点端口、节点状态、节点CPU、节点硬盘占用情况、虚拟资源、节点作业数。
5.3.2.5.消息异常
列表展示所有异常消息详细信息：消息类型、消息日期、消息描述；
5.3.2.6.TOP执行最久作业
选择需要统计某个系统、某个时间段内运行耗时最长的作业，然后展示出作业的详细信息，包括：作业的执行代理节点、作业所属系统、作业流名称、作业名称、作业执行代理节点的CPU概况等。
5.3.2.7.TOP历史出错率最高作业
选择需要统计某个系统、某个时间段内出错率最高的作业，然后展示出系统名称、容器、作业名称、作业运行批次、作业运行错误次数。
6、规划与实施
近年来，随着银行业务不断深入拓展，为了更好的支撑业务的发展，各大银行陆续建设了一批管理类应用系统，包括数据仓库系统、绩效考核系统、统一监管报送平台、资产负债系统，以及正在建设中的管理会计等多个业务系统。为了保障这些系统的正常运行，部署了各种批量处理调度。
由于这些业务平台都是由不同厂家在不同时期分批建设的。因此基本都各自采用了不同的批量调度方案，有的采用ETL工具Datastage自带的调度方案，有的是应用系统自身开发的调度方案，还有的采购了额外的调度工具等等。在一定时间的运行使用过程中，问题逐渐暴露出来。
以上这些现象，根本原因在于部分银行前期的规划与实施中，没有统一规划，合理有效的实施中造成。主要在两大平台方面：调度技术工具平台、统一调度监控平台。
6.1.主要实施内容
6.1.1.批量调度统一平台基础设施建设
6.1.1.1.调度技术工具平台
由于调度技术工具不统一、分散、各自系统独自建设，维护；存在调度系统重复建设严重，浪费人力资源开发；调度系统越多，技术体系就会越复杂。导致科技部人员在学习和运维上的压力越来越大。
不同厂商所采用的调度产品差异化很大。大多数在稳定性、易用性以及专业性以及调度效率都难以做到面面俱到，有的甚至还有比较严重的缺陷。
所以批量调度技术是与业务、系统无关的纯技术体系，其专业化、规范化与其它中间件一样，具有底层基础建设意义；十分有必要建设一个纯调度技术工具平台。
6.1.1.2.统一调度监控平台
不同厂商的调度平台协同性差，造成不同应用平台之间难以做到统一跑批调度。平台之间的依赖关系只能通过人工额外去处理，无法系统化管理。
站在全行IT设施管理的角度，对各系统批量调度技术体系进行统一监管，是企业综合统一监控管理平台不可或缺的重要组成部分；对企业级应用能够更高效的规范管理，起到提升工作效率，节省企业运行运维成本。
6.1.2.全行各应用系统批量调度应用推广
6.1.2.1.主要推广应用系统规划
在批量调度应用建设推广过程中，需要由银行内部高层管理人员负责抓此项目工作，从管理和技术贯彻公司意图，严把质量关，同时银行科技人员也要积极主动，自始自终参与技术标准、规范的制定工作。
6.1.2.2.调度应用推广主要方式
批量调度应用推广主要是集中在对技术平台的应用，技术上实现让每个具体的应用系统采用统一的技术平台来实现批量调度。在实施过程中主要有两种方式：原系统调度切换、新系统技术应用；
原系统调度切换，主要是对已经上线，正在生产运行中的系统的技术替换应用；产品提供商主导实施，银行客户自我主导实施。
新系统技术应用，对于银行内部即将要升级改造，或者新建系统的技术应用推广；第三方服务商主导实施。
6.1.2.3.调度应用推广过程的关键点
为了保证原系统切换过程中生产平稳过度，必须注意以下几点：
作业的完整统计：必须完整统计原有系统中存在哪些作业，不能遗漏任何一个作业；
作业控制方式统计：1、有几种作业类型；2、作业的调用方式；3、作业入口参数；4、作业的返回值；
作业的关系梳理：切换中的最大风险主要体现在关系梳理上，必须保证原来系统的作业关系不变基础上，才可根据具体业务属性优化调整关系。
6.2.实施规划原则建议
俗话说罗马不是一天建成的。任务平台系统的建设不是一下子就能建成的，都需要一个循序渐进的过程，调度应用建设需要一个分期建设原则。
原则一，纵向平台分期建设；需要先技术平台建设，后管理平台建设；技术平台是核心，只要把技术平台建设好，才可能以此为基础建设成一个统一的监控管理平台。
原则二，横向推广分期建设；应用推广主要基于技术平台进行，耍银行涉及批量的系统众多，无论是从风险的角度，还是大量系统应用实施科学的角度，都必须分期进行。
6.3.实施计划建议
实施计划建议划分为三个阶段：试点阶段、平台完善阶段、全面推广阶段。
试点阶段，批量应用建设第一期，先期实施一个典型的项目应用，最好选择数据类、调度作业轻量级的系统，主要集中在调度技术平台建设；比如CRM客户关系管理系统。实施方由产品原厂商主导实施，银行方面协助建设。建设周期1~2个月。
平台完善阶段，批量应用建设第二期，最好选择数据类、批量作业集中的系统，比如ECIF、ODS等传统业务系统，应用企业级监控平台建设；实施方由产品原成商、银行科技人员共同配合建设。建设周期3个月。第二期建设后，银行科技人员能够完成自主建设。
全面推广阶段，批量应用建设第三期，是一个长期的自主建设过程。银行科技人员自主完成应用到更多系统升级，或者应用到新建系统，或者自主主导应用到第三方集成商开发的新系统。