PowerJob/others/guidance/public/index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>介绍 on OhMyScheduler</title>
    <link>https://kfcfans.gitee.io/ohmyscheduler/</link>
    <description>Recent content in 介绍 on OhMyScheduler</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    
	<atom:link href="https://kfcfans.gitee.io/ohmyscheduler/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>容器</title>
      <link>https://kfcfans.gitee.io/ohmyscheduler/docs/super/container/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://kfcfans.gitee.io/ohmyscheduler/docs/super/container/</guid>
      <description>什么是容器？ 介绍 OhMyScheduler的容器技术允许开发者开发独立于Worker项目之外Java处理器，简单来说，就是以Maven工程项目的维度去组织一堆Java文件（开发者开发的众多脚本处理器），进而兼具开发效率和可维护性。
用途举例  比如，突然出现了某个数据库数据清理任务，与主业务无关，写进原本的项目工程中不太优雅，这时候就可以单独创建一个用于数据操作的容器，在里面完成处理器的开发，通过OhMyScheduler的容器部署技术在Worker集群上被加载执行。 比如，常见的日志清理啊，机器状态上报啊，对于广大Java程序员来说，也许并不是很会写shell脚本，此时也可以借用agent+容器技术，利用Java完成各项原本需要通过脚本进行的操作。  （感觉例子举的都不是很好&amp;hellip;这个东西嘛，只可意会不可言传，大家努力理解一下吧～超好用哦～）
生成容器模版 为了方便开发者使用，最新版本的前端页面已经支持容器工程模版的自动生成，开发者仅需要填入相关信息即可下载容器模版开始开发。   Group：对应Maven的&amp;lt;groupId&amp;gt;标签，一般填入倒写的公司域名。 Artifact：对于Maven的&amp;lt;artifactId&amp;gt;标签，填入代表该容器的唯一标示。 Name：对应Maven的&amp;lt;name&amp;gt;标签，填入该容器名称。 Package Name：包名，代表了的容器工程内部所使用的包名，警告：包名一旦生成后，请勿更改！否则会导致运行时容器加载错误（当然，如有必须修改包名的需求，可以尝试替换/resource下以oms-worker-container开头的所有文件相关的值）。 Java Version：容器工程的Java版本，请务必与容器目标部署Worker平台的Java版本保持一致。  开发容器工程 完成容器模版创建后，下载，解压，会得到如下结构的Java工程：
oms-template-origin // 工程名称，可以自由更改 ├── pom.xml └── src ├── main │ ├── java │ │ └── cn │ │ └── edu │ │ └── zju │ │ └── tjq │ │ └── container │ │ └── samples // 所有处理器代码必须位于该目录下，其余类随意 │ └── resources // 严禁随意更改以下两个配置文件（允许添加，不允许更改现有内容） │ ├── oms-worker-container-spring-context.xml │ └── oms-worker-container.</description>
    </item>
    
    <item>
      <title>更新日志</title>
      <link>https://kfcfans.gitee.io/ohmyscheduler/docs/version/update/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://kfcfans.gitee.io/ohmyscheduler/docs/version/update/</guid>
      <description>规范：语义化版本 为了避免后期维护困难，本框架需要时刻遵守如下准则：  版本格式：主版本号.次版本号.修订号
递增规则：
 主版本号：当做了不兼容的 API 修改 次版本号：当你做了向下兼容的功能性新增 修订号：当你做了向下兼容的问题修正  更新记录 v1.2.0 [2020.5.21]  新增容器扩展能力，极大提升系统的灵活性和扩展性。 新增OhMyAgent代理worker，与容器技术相结合可提供巨大的灵活可定制性。 新增“垃圾回收机制”，定期清理工作区产生的垃圾，降低磁盘占用。 新增OhMyClient高可用特性，允许开发者填入多个IP进行容错。 切换Web容器，为了获得更好的websocket支持，OhMyScheduler当前使用undertow取代Tomcat作为Web容器。 移除Worker自动寻找可用端口功能，目前仅使用配置文件制定的端口。 更改了worker序列化框架复用技术，从对象池切换到了ThreadLocal（为了容器技术而作出的微小性能牺牲）。 美化了前端页面（再次感谢某知名上市电商公司前端工程师对本项目的大力支持）！ 修复在线日志在部分情况下无法正确显示的BUG。 修复了若干（我想不起来了但是确实修复了的）BUG～  v1.1.0 [2020.5.11]  新增在线日志功能，可在控制台直接查看任务运行时日志，高效便捷！ 美化了部分前端页面（T_T） 修复若干BUG～  v1.0.0 [2020.4.20] 第一个正式版本，发布了以下特性：
 支持CRON、固定频率、固定延迟和API四种调度策略。 支持单机、广播、MapReduce三种执行模式。 支持任意的水平扩展，性能强劲无上限。 具有强大的故障转移与恢复能力，只要保证集群可用节点数足够，任务就能顺利完成。 仅依赖数据库，部署简单，上手容易，开发高效，仅需几行代码即可获得整个集群的分布式计算能力。 支持SpringBean、普通Java类（内置/外置）、Shell、Python等处理器。  </description>
    </item>
    
    <item>
      <title>调度中心（Server）部署</title>
      <link>https://kfcfans.gitee.io/ohmyscheduler/docs/startup/1-server-startup/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://kfcfans.gitee.io/ohmyscheduler/docs/startup/1-server-startup/</guid>
      <description>环境要求   Open JDK 8+
  Apache Maven 3+
  任意 Spring Data Jpa 支持的关系型数据库（MySQL/Oracle/MS SQLServer&amp;hellip;）
  MongoDB（可选），任意支持GridFS的mongoDB版本（4.2.6测试通过，其余未经测试，仅从理论角度分析可用），缺失该组件的情况下将无法使用在线日志、容器部署等扩展功能
  初始化关系数据库  调度服务器（oh-my-scheduler-server）的持久化层基于Spring Boot Jpa实现，对于能够直连数据库的应用，开发者仅需完成数据库的创建，即运行SQL：CREATE database if NOT EXISTS oms-product default character set utf8mb4 collate utf8mb4_unicode_ci;`
  OhMyScheduler支持环境隔离，提供日常（daily）、预发（pre）和线上（product）三套环境，请根据使用的环境分别部署对应的数据库：oms-daily、oms-pre和oms-product。 调度服务器属于时间敏感应用，强烈建议检查当前数据库所使用的时区信息（show variables like &amp;quot;%time_zone%&amp;quot;;），务必确保time_zone代表的时区与JDBC URL中serverTimezone字段代表的时区一致！ 手动建表表SQL文件：下载地址  部署调度服务器—源码编译  调度服务器（oh-my-scheduler-server）支持任意的水平扩展，即多实例集群部署仅需要在同一个局域网内启动新的服务器实例，性能强劲无上限！
 调度服务器（oh-my-scheduler-server）为了支持环境隔离，分别采用了日常（application-daily.properties）、预发（application-pre.properties）和线上（application-product.properties）三套配置文件，请根据实际需求进行修改，以下为配置文件详解。
   配置项 含义 可选     server.port SpringBoot配置，HTTP端口号，默认7700 否   oms.</description>
    </item>
    
    <item>
      <title>OpenAPI</title>
      <link>https://kfcfans.gitee.io/ohmyscheduler/docs/super/openapi/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://kfcfans.gitee.io/ohmyscheduler/docs/super/openapi/</guid>
      <description>OpenAPI允许开发者通过接口来完成手工的操作，让系统整体变得更加灵活。开发者可以基于API便捷地扩展OhMyScheduler原有的功能。  依赖 最新依赖版本请参考Maven中央仓库：推荐地址&amp;amp;备用地址。
&amp;lt;dependency&amp;gt; &amp;lt;groupId&amp;gt;com.github.kfcfans&amp;lt;/groupId&amp;gt; &amp;lt;artifactId&amp;gt;oh-my-scheduler-client&amp;lt;/artifactId&amp;gt; &amp;lt;version&amp;gt;1.2.0&amp;lt;/version&amp;gt; &amp;lt;/dependency&amp;gt; 简单示例 // 初始化 client，需要server地址和应用名称作为参数 OhMyClient ohMyClient = new OhMyClient(&amp;#34;127.0.0.1:7700&amp;#34;, &amp;#34;oms-test&amp;#34;); // 调用相关的API ohMyClient.stopInstance(1586855173043L) API列表 创建/修改任务 接口签名：ResultDTO&amp;lt;Long&amp;gt; saveJob(ClientJobInfo newJobInfo)
入参：任务信息（详细说明见下表，也可以参考前端任务创建各参数的正确填法）
返回值：ResultDTO，根据success判断操作是否成功。若操作成功，data字段返回任务ID
   属性 说明     jobId 任务ID，可选，null代表创建任务，否则填写需要修改的任务ID   jobName 任务名称   jobDescription 任务描述   jobParams 任务参数，Processor#process方法入参TaskContext对象的jobParams字段   timeExpressionType 时间表达式类型，枚举值   timeExpression 时间表达式，填写类型由timeExpressionType决定，比如CRON需要填写CRON表达式   executeType 执行类型，枚举值   processorType 处理器类型，枚举值   processorInfo 处理器参数，填写类型由processorType决定，如Java处理器需要填写全限定类名，如：com.</description>
    </item>
    
    <item>
      <title>执行器（Worker）初始化</title>
      <link>https://kfcfans.gitee.io/ohmyscheduler/docs/startup/2-worker-startup/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://kfcfans.gitee.io/ohmyscheduler/docs/startup/2-worker-startup/</guid>
      <description>基于宿主应用的执行器初始化  宿主应用即原有的业务应用，假如需要调度执行的任务与当前业务有较为紧密的联系，建议采取该方式。
 首先，添加相关的jar包依赖，最新依赖版本请参考maven中央仓库：推荐地址&amp;amp;备用地址
&amp;lt;dependency&amp;gt; &amp;lt;groupId&amp;gt;com.github.kfcfans&amp;lt;/groupId&amp;gt; &amp;lt;artifactId&amp;gt;oh-my-scheduler-worker&amp;lt;/artifactId&amp;gt; &amp;lt;version&amp;gt;1.2.0&amp;lt;/version&amp;gt; &amp;lt;/dependency&amp;gt; 其次，填写执行器客户端配置文件OhMyConfig，各参数说明如下表所示：
   属性名称 含义 默认值     appName 宿主应用名称，需要提前在控制台完成注册 无，必填项，否则启动报错   port Worker工作端口 27777   serverAddress 调度中心（oh-my-scheduler-server）地址列表 无，必填项，否则启动报错   storeStrategy 本地存储策略，枚举值磁盘/内存，大型MapReduce等会产生大量Task的任务推荐使用磁盘降低内存压力，否则建议使用内存加速计算 StoreStrategy.DISK（磁盘）   maxResultLength 每个Task返回结果的默认长度，超长将被截断。过长可能导致网络拥塞 8096   enableTestMode 是否启用测试模式，启用后无需Server也能顺利启动OhMyScheduler-Worker，用于处理器本地的单元测试 false    最后，初始化客户端，完成执行器的启动，代码示例如下：
@Configuration public class OhMySchedulerConfig { @Bean public OhMyWorker initOMS() throws Exception { // 服务器HTTP地址（端口号为 server.port，而不是 ActorSystem port）  List&amp;lt;String&amp;gt; serverAddress = Lists.</description>
    </item>
    
    <item>
      <title>迁移指南</title>
      <link>https://kfcfans.gitee.io/ohmyscheduler/docs/version/migrate/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://kfcfans.gitee.io/ohmyscheduler/docs/version/migrate/</guid>
      <description>记录当发生不兼容的版本变更时，开发者需要做出的升级和迁移。  暂无</description>
    </item>
    
    <item>
      <title>处理器开发</title>
      <link>https://kfcfans.gitee.io/ohmyscheduler/docs/startup/3-processor-develop/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://kfcfans.gitee.io/ohmyscheduler/docs/startup/3-processor-develop/</guid>
      <description>处理器概述  OhMyScheduler当前支持Shell、Python等脚本处理器和Java处理器。脚本处理器只需要开发者完成脚本的编写（xxx.sh / xxx.py），在控制台填入脚本内容即可，本章不再赘述。本章将重点阐述Java处理器开发方法与使用技巧。
  Java处理器可根据代码所处位置划分为内置Java处理器和容器Java处理器，前者直接集成在宿主应用（也就是接入本系统的业务应用）中，一般用来处理业务需求；后者可以在一个独立的轻量级的Java工程中开发，通过容器技术（详见容器章节）被worker集群热加载，提供Java的“脚本能力”，一般用于处理灵活多变的需求。 Java处理器可根据对象创建者划分为SpringBean处理器和普通Java对象处理器，前者由Spring IOC容器完成处理器的创建和初始化，后者则有OhMyScheduler维护其状态。如果宿主应用支持Spring，强烈建议使用SpringBean处理器，开发者仅需要将Processor注册进Spring IOC容器（一个@Component注解或一句bean配置）。 Java处理器可根据功能划分为单机处理器、广播处理器、Map处理器和MapReduce处理器。  单机处理器（BasicProcessor）对应了单机任务，即某个任务的某次运行只会有某一台机器的某一个线程参与运算。 广播处理器（BroadcastProcessor）对应了广播任务，即某个任务的某次运行会调动集群内所有机器参与运算。 Map处理器（MapProcessor）对应了Map任务，即某个任务在运行过程中，允许产生子任务并分发到其他机器进行运算。 MapReduce处理器（MapReduceProcessor）对应了MapReduce任务，在Map任务的基础上，增加了所有任务结束后的汇总统计。    核心方法：process 任意Java处理器都需要实现处理的核心方法，其接口签名如下：
ProcessResult process(TaskContext context) throws Exception; 方法入参TaskContext，包含了本次处理的上下文信息，具体属性如下：
   属性名称 意义/用法     jobId 任务ID，开发者一般无需关心此参数   instanceId 任务实例ID，全局唯一，开发者一般无需关心此参数   subInstanceId 子任务实例ID，秒级任务使用，开发者一般无需关心此参数   taskId 采用链式命名法的ID，在某个任务实例内唯一，开发者一般无需关心此参数   taskName task名称，Map/MapReduce任务的子任务的值为开发者指定，否则为系统默认值，开发者一般无需关心此参数   jobParams 任务参数，其值等同于控制台录入的任务参数，常用！   instanceParams 任务实例参数，其值等同于使用OpenAPI运行任务实例时传递的参数，常用！   maxRetryTimes Task的最大重试次数   currentRetryTimes Task的当前重试次数，和maxRetryTimes联合起来可以判断当前是否为该Task的最后一次运行机会   subTask 子Task，Map/MapReduce处理器专属，开发者调用map方法时传递的子任务列表中的某一个   omsLogger 在线日志，用法同Slf4J，记录的日志可以直接通过控制台查看，非常便捷和强大！不过使用过程中需要注意频率，可能对Server造成巨大的压力    方法的返回值为ProcessResult，代表了本次Task执行的结果，包含success和msg两个属性，分别用于传递Task是否执行成功和Task需要返回的信息。</description>
    </item>
    
    <item>
      <title>任务管理与在线运维</title>
      <link>https://kfcfans.gitee.io/ohmyscheduler/docs/startup/4-console-guide/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://kfcfans.gitee.io/ohmyscheduler/docs/startup/4-console-guide/</guid>
      <description>前端控制台允许开发者可视化地进行任务增、删、改、查等管理操作，同时也能直观地看到任务的运行数据，包括运行状态、详情和在线日志等。以下为对控制台的详细介绍：  主页 展示了系统整体的概览和集群Worker列表。
任务创建 创建需要被调度执行的任务，入口为主页 -&amp;gt; 任务管理 -&amp;gt; 新建任务。
  任务名称：名称，便于记忆与搜索，无特殊用途，请尽量简短（占用数据库字段空间）
  任务描述：描述，无特殊作用，请尽量简短（占用数据库字段空间）
  任务参数：任务处理时能够获取到的参数（即各个Processor的process方法入参TaskContext对象的jobParams字段）（进行一次处理器开发就能理解了）
  定时信息：由下拉框和输入框组成
 API -&amp;gt; 不需要填写任何参数（填了也不起作用） CRON -&amp;gt; 填写 CRON 表达式（可以找个在线生成网站生成） 固定频率 -&amp;gt; 填写整数，单位毫秒 固定延迟 -&amp;gt; 填写整数，单位毫秒    执行配置：由执行类型（单机、广播和MapReduce）、处理器类型和处理器参数组成，后两项相互关联。
 内置Java处理器 -&amp;gt; 填写该处理器的全限定类名（eg, com.github.kfcfans.oms.processors.demo.MapReduceProcessorDemo） Java容器 -&amp;gt; 填写容器ID#处理器全限定类名（eg，1#com.github.kfcfans.oms.container.DemoProcessor） SHELL -&amp;gt; 填写需要处理的脚本（直接复制文件内容）或脚本下载连接（http://xxx） PYTHON -&amp;gt; 填写完整的python脚本或下载连接（http://xxx）    运行配置
 最大实例数：该任务同时执行的数量（任务和实例就像是类和对象的关系，任务被调度执行后被称为实例） 单机线程并发数：该实例执行过程中每个Worker使用的线程数量（MapReduce任务生效，其余无论填什么，都只会使用1个线程或3个线程&amp;hellip;） 运行时间限制：限定任务的最大运行时间，超时则视为失败，单位毫秒，0代表不限制超时时间。    重试配置：
 任务重试次数：实例级别，失败了整个任务实例重试，会更换TaskTracker（本次任务实例的Master节点），代价较大，大型Map/MapReduce慎用。 子任务重试次数：Task级别，每个子Task失败后单独重试，会更换ProcessorTracker（本次任务实际执行的Worker节点），代价较小，推荐使用。 注：对于单机任务来说，假如任务重试次数和子任务重试次数都配置了1且都执行失败，实际执行次数会变成4次！推荐任务实例重试配置为0，子任务重试次数根据实际情况配置。    机器配置：用来标明允许执行任务的机器状态，避开那些摇摇欲坠的机器，0代表无任何限制。</description>
    </item>
    
    <item>
      <title>开发计划</title>
      <link>https://kfcfans.gitee.io/ohmyscheduler/docs/todo/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://kfcfans.gitee.io/ohmyscheduler/docs/todo/</guid>
      <description>截止目前（v1.2.0），框架的基本功能（调度和分布式计算）已经趋于稳定，大家可以放心接入使用。不过为了使框架更为成熟易用，仍有需要不断改进和开发的地方。  下阶段规划  支持DAG工作流 任务的优先级系统，需要可抢占式实现，而不是SchedulerX那种傻等式 在线日志的限流 &amp;amp; 本地数据库分表提升在线日志最大吞吐量 保护性判断（优先级较低，太繁琐了且意义不大，毕竟面向开发者，大家不会乱填参数对不对～）  共同建设邀请 (❁´◡`❁)✲ﾟ 都看到这里了，相比您对本项目产生了浓厚的兴趣，欢迎加入开源社区，为框架贡献自己的力量～
（PR、Issue求求了～）
如果有什么想法、建议或意见，都欢迎联系作者：tengjiqi@gmail.com。</description>
    </item>
    
    <item>
      <title>FAQ</title>
      <link>https://kfcfans.gitee.io/ohmyscheduler/docs/faq/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://kfcfans.gitee.io/ohmyscheduler/docs/faq/</guid>
      <description>这里记录一些好问题和高频问题。  Q：生成环境能用吗？ A：可以。框架从发布到现在已经趋于稳定，且开发者@KFCFans当前有充足的时间维护框架，一旦发现bug，可以联系我，保证第一时间修复！
Q：请问，有没有通过API增删改查执行的操作？ A：OpenAPI就是为此而生的。OpenAPI在Http的基础上进行了封装，提供规范的接口完成任务的管理与运维。
Q：Ignite也支持分布式计算，请问这个项目有什么优势？ A：从本质上讲，OhMyScheduler是一个具有分布式计算能力的调度平台，而Ignite是一个分布式计算平台，前者立足于调度（虽然本项目的亮点是分布式计算没错啦…），后者立足于大数据计算，两者立足点不同。
从分布式计算的角度来讲，Ignite确实具备全部OhMyScheduler的功能（毕竟人家是Apache顶级项目&amp;hellip;），OhMyScheduler-Worker集群可以看成嵌入式的Ignite集群，整体对外提供服务。两者虽然表面上功能有所重合，但背后的设计理念是截然不同的。
Ignite本质上是由分布式内存SQL数据库发展而来的分布式计算平台，它解决的问题更偏向于大数据处理（Spark、Hadoop之类），因此对于传统的Java项目并不是非常友好，比如官方推荐的部署模式是建立独立的Ignite集群负责计算，业务应用只负责提交代码。再比如获取各种资源（Spring Bean）都需要先注入Ignite中，这对于依赖繁杂的业务来说是非常痛苦的。
而OhMyScheduler就是面向业务应用设计的，从示例代码中也能看出，开发OhMyScheduler的处理器是没有任何额外的成本的，想要某个SpringBean，直接注入即可。想要分发任务，调用map方法即可，开发者的学习和使用成本会低很多。
一句话总结就是：Ignite的分布式计算偏向于数据侧，适用于大数据处理。而OhMyScheduler的分布式计算偏向于业务侧，适用于传统Java应用的业务处理。
此外，高效开发一直是OhMyScheduler的设计理念，像在线查看任务运行情况、在线查看任务运行日志等功能，在实际开发中将会非常实用。</description>
    </item>
    
  </channel>
</rss>