@things-factory/scheduler 9.0.3 → 9.0.20
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -1,50 +1,255 @@
|
|
|
1
|
-
#
|
|
1
|
+
# 调度器服务
|
|
2
2
|
|
|
3
|
-
-
|
|
4
|
-
-
|
|
5
|
-
-
|
|
6
|
-
-
|
|
3
|
+
- 在调度器中注册的所有事件都使用各种调度类型和值(包括cron)进行指定
|
|
4
|
+
- 根据用户指定的调度类型调用事件,通常调用的事件会调用注册时指定的REST API
|
|
5
|
+
- 如果调用的事件失败,会根据策略在特定时间后重试
|
|
6
|
+
- 为了分散调度器处理的负载,新设计的结构使用基于数据库的队列来管理所有调度数据
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
## 🚀 独特功能
|
|
9
|
+
|
|
10
|
+
### 1. 五维客户端标识符系统
|
|
11
|
+
|
|
12
|
+
调度器使用独特的五维客户端标识系统,超越了简单的基于UUID的标识:
|
|
13
|
+
|
|
14
|
+
```json
|
|
15
|
+
{
|
|
16
|
+
"client": {
|
|
17
|
+
"application": "data-collection-app",
|
|
18
|
+
"group": "domain-123",
|
|
19
|
+
"type": "data-set",
|
|
20
|
+
"key": "sensor-001",
|
|
21
|
+
"operation": "collect"
|
|
22
|
+
}
|
|
23
|
+
}
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
**主要优势:**
|
|
27
|
+
|
|
28
|
+
- **业务上下文感知**:标识符反映业务含义而非技术ID
|
|
29
|
+
- **重复防止**:只有5个元素都匹配的调度才被认为是相同的
|
|
30
|
+
- **自然组织**:从application → group → type → key → operation的层次结构
|
|
31
|
+
- **灵活过滤**:通过客户端属性的任意组合过滤调度
|
|
32
|
+
|
|
33
|
+
### 2. 创新的调度类型
|
|
34
|
+
|
|
35
|
+
#### delay-recur:革命性的重复模式
|
|
36
|
+
|
|
37
|
+
```json
|
|
38
|
+
{
|
|
39
|
+
"type": "delay-recur",
|
|
40
|
+
"schedule": "30",
|
|
41
|
+
"timezone": "UTC"
|
|
42
|
+
}
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
- **简单重复**:30秒间隔,无需复杂的cron表达式
|
|
46
|
+
- **实时优化**:完美适用于监控、心跳和数据同步
|
|
47
|
+
- **资源效率**:比传统的基于cron的方法更轻量
|
|
48
|
+
|
|
49
|
+
#### 全面的调度类型支持
|
|
50
|
+
|
|
51
|
+
- **now**:立即执行
|
|
52
|
+
- **delay**:一次性延迟执行
|
|
53
|
+
- **date**:特定日期/时间执行
|
|
54
|
+
- **cron**:传统的基于cron的调度
|
|
55
|
+
- **delay-recur**:创新的重复模式
|
|
56
|
+
|
|
57
|
+
### 3. 高级失败处理
|
|
58
|
+
|
|
59
|
+
#### retry_dlq:混合失败策略
|
|
60
|
+
|
|
61
|
+
```json
|
|
62
|
+
{
|
|
63
|
+
"failed_policy": "retry_dlq",
|
|
64
|
+
"retry_wait": 60,
|
|
65
|
+
"max_retry_count": 3
|
|
66
|
+
}
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
**三阶段失败处理:**
|
|
70
|
+
|
|
71
|
+
1. **立即重试**:通过指数退避进行快速重试
|
|
72
|
+
2. **最大重试**:最多配置的最大尝试次数
|
|
73
|
+
3. **死信队列**:失败的任务移动到DLQ以便稍后处理
|
|
74
|
+
|
|
75
|
+
**优势:**
|
|
76
|
+
|
|
77
|
+
- **系统稳定性**:防止无限重试循环
|
|
78
|
+
- **数据保护**:即使失败也不会丢失数据
|
|
79
|
+
- **问题诊断**:DLQ支持失败分析
|
|
80
|
+
|
|
81
|
+
### 4. 历史感知调度
|
|
82
|
+
|
|
83
|
+
#### history_check:执行历史管理
|
|
84
|
+
|
|
85
|
+
```json
|
|
86
|
+
{
|
|
87
|
+
"history_check": true
|
|
88
|
+
}
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
**功能:**
|
|
92
|
+
|
|
93
|
+
- **重复防止**:避免重新执行已完成的任务
|
|
94
|
+
- **基于状态的决策**:基于执行历史做出调度决策
|
|
95
|
+
- **审计跟踪**:用于合规和调试的完整执行历史
|
|
96
|
+
|
|
97
|
+
### 5. 域感知回调系统
|
|
98
|
+
|
|
99
|
+
#### 多租户支持
|
|
100
|
+
|
|
101
|
+
```json
|
|
102
|
+
{
|
|
103
|
+
"task": {
|
|
104
|
+
"connection": {
|
|
105
|
+
"host": "http://localhost:3000/domain/company/callback-schedule-for-dataset"
|
|
106
|
+
}
|
|
107
|
+
}
|
|
108
|
+
}
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
**优势:**
|
|
112
|
+
|
|
113
|
+
- **租户隔离**:每个域的调度独立处理
|
|
114
|
+
- **自动URL生成**:域上下文自动包含在回调URL中
|
|
115
|
+
- **安全性**:基于域的访问控制和数据隔离
|
|
116
|
+
|
|
117
|
+
### 调度器周期性处理的图表
|
|
9
118
|
|
|
10
119
|

|
|
11
120
|
|
|
12
|
-
-
|
|
13
|
-
-
|
|
121
|
+
- **优势**:结构简单,无需额外服务即可运行
|
|
122
|
+
- **劣势**:每个实例必须周期性唤醒并检查数据库中的调度队列,无空闲期
|
|
14
123
|
|
|
15
|
-
###
|
|
124
|
+
### 替代方案:监控实例周期性检查调度器唤醒时间并向所有调度器发布的结构
|
|
16
125
|
|
|
17
126
|

|
|
18
127
|
|
|
19
|
-
-
|
|
20
|
-
-
|
|
128
|
+
- 所有实例基于从监控实例接收的下一个调度时间戳信息处理调度
|
|
129
|
+
- **要求**:需要额外服务(如Redis),每个实例必须持续持有下一个调度的信息
|
|
21
130
|
|
|
22
|
-
## MSA
|
|
131
|
+
## MSA中的调度器服务
|
|
23
132
|
|
|
24
133
|

|
|
25
134
|
|
|
26
|
-
-
|
|
27
|
-
-
|
|
28
|
-
-
|
|
135
|
+
- 传统应用程序结构中处理调度作业的调度器服务无法在基于云的水平扩展架构中运行
|
|
136
|
+
- 需要单独的调度器服务。虽然有许多此类任务的服务,但没有专门仅用于调度角色的服务
|
|
137
|
+
- 需要可在云环境中水平扩展的可扩展服务
|
|
29
138
|
|
|
30
|
-
##
|
|
139
|
+
## 服务概述
|
|
31
140
|
|
|
32
141
|

|
|
33
142
|
|
|
34
|
-
-
|
|
35
|
-
- MSA
|
|
143
|
+
- 调度器服务是基于RESTful架构的水平可扩展调度服务
|
|
144
|
+
- 它提供了一种服务,在基于MSA的应用程序环境中将调度模块与现有应用程序分离
|
|
36
145
|
|
|
37
|
-
##
|
|
146
|
+
## 🎯 使用案例和最佳实践
|
|
38
147
|
|
|
39
|
-
|
|
40
|
-
- 특정한 날짜 혹은 특정한 주기로 실행되는 태스크 실행 엔진
|
|
41
|
-
- 특정한 이벤트를 등록 관리하고, 이벤트를 기반으로 특정 기능을 실행하거나 데이터를 전달하는 브로커
|
|
148
|
+
### 实时监控
|
|
42
149
|
|
|
43
|
-
|
|
150
|
+
```json
|
|
151
|
+
{
|
|
152
|
+
"name": "sensor-monitoring",
|
|
153
|
+
"client": {
|
|
154
|
+
"application": "iot-platform",
|
|
155
|
+
"group": "factory-001",
|
|
156
|
+
"type": "sensor",
|
|
157
|
+
"key": "temperature-sensor-01",
|
|
158
|
+
"operation": "monitor"
|
|
159
|
+
},
|
|
160
|
+
"type": "delay-recur",
|
|
161
|
+
"schedule": "30",
|
|
162
|
+
"timezone": "Asia/Seoul",
|
|
163
|
+
"task": {
|
|
164
|
+
"type": "rest",
|
|
165
|
+
"connection": {
|
|
166
|
+
"host": "http://localhost:3000/api/sensor/collect",
|
|
167
|
+
"headers": { "Content-Type": "application/json" }
|
|
168
|
+
},
|
|
169
|
+
"data": { "sensorId": "temp-001", "threshold": 25 },
|
|
170
|
+
"history_check": true,
|
|
171
|
+
"failed_policy": "retry_dlq",
|
|
172
|
+
"retry_wait": 60,
|
|
173
|
+
"max_retry_count": 3
|
|
174
|
+
}
|
|
175
|
+
}
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
### 数据同步
|
|
44
179
|
|
|
45
|
-
|
|
180
|
+
```json
|
|
181
|
+
{
|
|
182
|
+
"name": "data-sync",
|
|
183
|
+
"client": {
|
|
184
|
+
"application": "erp-system",
|
|
185
|
+
"group": "company-abc",
|
|
186
|
+
"type": "inventory",
|
|
187
|
+
"key": "daily-sync",
|
|
188
|
+
"operation": "sync"
|
|
189
|
+
},
|
|
190
|
+
"type": "cron",
|
|
191
|
+
"schedule": "0 2 * * *",
|
|
192
|
+
"timezone": "Asia/Seoul",
|
|
193
|
+
"task": {
|
|
194
|
+
"type": "kafka",
|
|
195
|
+
"connection": {
|
|
196
|
+
"host": "localhost:9092",
|
|
197
|
+
"topic": "inventory-sync"
|
|
198
|
+
},
|
|
199
|
+
"data": { "syncType": "full", "timestamp": "2024-01-01T02:00:00Z" },
|
|
200
|
+
"history_check": true,
|
|
201
|
+
"failed_policy": "retry_dlq",
|
|
202
|
+
"retry_wait": 300,
|
|
203
|
+
"max_retry_count": 5
|
|
204
|
+
}
|
|
205
|
+
}
|
|
206
|
+
```
|
|
46
207
|
|
|
47
|
-
|
|
208
|
+
### 报告生成
|
|
209
|
+
|
|
210
|
+
```json
|
|
211
|
+
{
|
|
212
|
+
"name": "daily-report",
|
|
213
|
+
"client": {
|
|
214
|
+
"application": "analytics-platform",
|
|
215
|
+
"group": "marketing-team",
|
|
216
|
+
"type": "report",
|
|
217
|
+
"key": "daily-metrics",
|
|
218
|
+
"operation": "generate"
|
|
219
|
+
},
|
|
220
|
+
"type": "cron",
|
|
221
|
+
"schedule": "0 9 * * 1-5",
|
|
222
|
+
"timezone": "Asia/Seoul",
|
|
223
|
+
"task": {
|
|
224
|
+
"type": "rest",
|
|
225
|
+
"connection": {
|
|
226
|
+
"host": "http://localhost:3000/api/reports/generate",
|
|
227
|
+
"headers": { "Authorization": "Bearer ..." }
|
|
228
|
+
},
|
|
229
|
+
"data": { "reportType": "daily", "recipients": ["team@company.com"] },
|
|
230
|
+
"history_check": true,
|
|
231
|
+
"failed_policy": "retry",
|
|
232
|
+
"retry_wait": 1800,
|
|
233
|
+
"max_retry_count": 2
|
|
234
|
+
}
|
|
235
|
+
}
|
|
236
|
+
```
|
|
237
|
+
|
|
238
|
+
## 可用场景
|
|
239
|
+
|
|
240
|
+
- **基于Cron的调度作业处理器**:用于在特定间隔处理任务
|
|
241
|
+
- **任务执行引擎**:用于在特定日期或特定间隔执行任务
|
|
242
|
+
- **事件驱动的任务处理器**:用于注册和管理事件,并基于这些事件执行特定任务或传输数据
|
|
243
|
+
- **实时监控**:使用delay-recur进行短间隔的连续监控
|
|
244
|
+
- **数据同步**:系统间的周期性数据同步
|
|
245
|
+
- **报告生成**:自动化报告生成和分发
|
|
246
|
+
- **IoT设备管理**:管理IoT设备通信和数据收集
|
|
247
|
+
|
|
248
|
+
### 调度
|
|
249
|
+
|
|
250
|
+
#### 格式
|
|
251
|
+
|
|
252
|
+
注册调度的格式示例如下:
|
|
48
253
|
|
|
49
254
|
```json
|
|
50
255
|
{
|
|
@@ -73,28 +278,28 @@
|
|
|
73
278
|
}
|
|
74
279
|
```
|
|
75
280
|
|
|
76
|
-
- name
|
|
77
|
-
- client
|
|
78
|
-
- operation
|
|
79
|
-
- application
|
|
80
|
-
- group
|
|
81
|
-
- key
|
|
82
|
-
-
|
|
83
|
-
- type
|
|
84
|
-
- schedule
|
|
85
|
-
- timezone
|
|
86
|
-
- task
|
|
87
|
-
- type
|
|
88
|
-
- connection
|
|
89
|
-
- host
|
|
90
|
-
- topic
|
|
91
|
-
- headers
|
|
92
|
-
- data
|
|
93
|
-
- history_check
|
|
94
|
-
|
|
95
|
-
###
|
|
96
|
-
|
|
97
|
-
- delay
|
|
281
|
+
- **name**:调度的名称
|
|
282
|
+
- **client**:表示客户端信息。只有当所有五个元素都匹配时,调度才被认为是相同的
|
|
283
|
+
- **operation**:表示特定的调度目的,如流程
|
|
284
|
+
- **application**:客户端应用程序的名称
|
|
285
|
+
- **group**:域信息
|
|
286
|
+
- **key**:用于调度区分的单独密钥
|
|
287
|
+
- **type**:调度本身的资源类型
|
|
288
|
+
- **type**:主要类型包括`cron`、`now`、`date`、`delay`和`delay-recur`。详细描述请参阅"调度器类型"部分
|
|
289
|
+
- **schedule**:根据调度类型指定的字符串。详情请参阅"调度器类型"
|
|
290
|
+
- **timezone**:用于调度处理的时区字符串(如`Asia/Seoul`)
|
|
291
|
+
- **task**:包含调度触发时需要执行的必要任务信息
|
|
292
|
+
- **type**:指定任务类型,如`rest`、`kafka`或`redis`。对于`rest`,仅支持POST
|
|
293
|
+
- **connection**:任务执行的连接信息
|
|
294
|
+
- **host**:服务器连接信息
|
|
295
|
+
- **topic**:用于`kafka`和`redis`类型
|
|
296
|
+
- **headers**:对于`rest`类型可选
|
|
297
|
+
- **data**:指定任务执行期间要传递的数据
|
|
298
|
+
- **history_check**:在单独的数据库中保存调度注册、执行、删除和重新执行的历史记录
|
|
299
|
+
|
|
300
|
+
### 调度类型
|
|
301
|
+
|
|
302
|
+
- **delay**:等待特定时间(秒)后执行调度
|
|
98
303
|
|
|
99
304
|
```json
|
|
100
305
|
{
|
|
@@ -106,7 +311,7 @@
|
|
|
106
311
|
}
|
|
107
312
|
```
|
|
108
313
|
|
|
109
|
-
- delay-recur
|
|
314
|
+
- **delay-recur**:等待特定时间(秒)后重复执行调度
|
|
110
315
|
|
|
111
316
|
```json
|
|
112
317
|
{
|
|
@@ -118,10 +323,9 @@
|
|
|
118
323
|
}
|
|
119
324
|
```
|
|
120
325
|
|
|
121
|
-
- cron
|
|
122
|
-
|
|
123
|
-
-
|
|
124
|
-
- 초 단위 스케줄리을 실행하기 위해서는 6개 시간 요소가 필요하면, 첫번째 요소가 초를 지정합니다.
|
|
326
|
+
- **cron**:基于cron格式运行
|
|
327
|
+
- 使用基本的五元素格式
|
|
328
|
+
- 对于秒级调度,需要六元素格式,其中第一个元素指定秒
|
|
125
329
|
|
|
126
330
|
```json
|
|
127
331
|
{
|
|
@@ -133,7 +337,7 @@
|
|
|
133
337
|
}
|
|
134
338
|
```
|
|
135
339
|
|
|
136
|
-
- date
|
|
340
|
+
- **date**:指定特定日期和时间(ISO格式,`YYYY-MM-DDThh:mm:ss`)
|
|
137
341
|
|
|
138
342
|
```json
|
|
139
343
|
{
|
|
@@ -145,7 +349,8 @@
|
|
|
145
349
|
}
|
|
146
350
|
```
|
|
147
351
|
|
|
148
|
-
- now
|
|
352
|
+
- **now**:立即执行调度
|
|
353
|
+
|
|
149
354
|
```json
|
|
150
355
|
{
|
|
151
356
|
...
|
|
@@ -156,9 +361,9 @@
|
|
|
156
361
|
}
|
|
157
362
|
```
|
|
158
363
|
|
|
159
|
-
###
|
|
364
|
+
### 任务类型
|
|
160
365
|
|
|
161
|
-
- Rest
|
|
366
|
+
- **Rest**
|
|
162
367
|
|
|
163
368
|
```json
|
|
164
369
|
{
|
|
@@ -171,7 +376,7 @@
|
|
|
171
376
|
}
|
|
172
377
|
```
|
|
173
378
|
|
|
174
|
-
- Kafka & Redis
|
|
379
|
+
- **Kafka & Redis**
|
|
175
380
|
|
|
176
381
|
```json
|
|
177
382
|
{
|
|
@@ -183,3 +388,77 @@
|
|
|
183
388
|
}
|
|
184
389
|
}
|
|
185
390
|
```
|
|
391
|
+
|
|
392
|
+
## 🔧 高级配置
|
|
393
|
+
|
|
394
|
+
### 重试策略
|
|
395
|
+
|
|
396
|
+
#### ignore
|
|
397
|
+
|
|
398
|
+
- 无重试尝试
|
|
399
|
+
- 适用于非关键任务
|
|
400
|
+
|
|
401
|
+
#### retry
|
|
402
|
+
|
|
403
|
+
- 带指数退避的简单重试
|
|
404
|
+
- 适用于临时失败
|
|
405
|
+
|
|
406
|
+
#### retry_dlq
|
|
407
|
+
|
|
408
|
+
- 带死信队列回退的重试
|
|
409
|
+
- 最适合需要数据保护的关键任务
|
|
410
|
+
|
|
411
|
+
### 历史检查配置
|
|
412
|
+
|
|
413
|
+
#### true
|
|
414
|
+
|
|
415
|
+
- 防止重复执行
|
|
416
|
+
- 维护执行历史
|
|
417
|
+
- 适用于数据收集和报告
|
|
418
|
+
|
|
419
|
+
#### false
|
|
420
|
+
|
|
421
|
+
- 允许多次执行
|
|
422
|
+
- 无历史跟踪
|
|
423
|
+
- 适用于实时监控
|
|
424
|
+
|
|
425
|
+
### 时区考虑
|
|
426
|
+
|
|
427
|
+
- **全球部署**:支持多时区
|
|
428
|
+
- **营业时间**:基于当地营业时间的调度执行
|
|
429
|
+
- **DST处理**:自动夏令时调整
|
|
430
|
+
|
|
431
|
+
## 🚀 性能优化
|
|
432
|
+
|
|
433
|
+
### 最佳实践
|
|
434
|
+
|
|
435
|
+
1. **对短间隔使用delay-recur**:比cron更高效用于频繁任务
|
|
436
|
+
2. **对数据任务实现history_check**:防止重复数据处理
|
|
437
|
+
3. **配置适当的重试策略**:平衡可靠性和性能
|
|
438
|
+
4. **使用时区感知调度**:确保准确的执行时间
|
|
439
|
+
5. **监控DLQ**:定期检查和处理失败的任务
|
|
440
|
+
|
|
441
|
+
### 扩展考虑
|
|
442
|
+
|
|
443
|
+
- **水平扩展**:多个调度器实例可以同时运行
|
|
444
|
+
- **负载分布**:基于数据库的队列在实例间分布负载
|
|
445
|
+
- **故障转移支持**:实例宕机时自动故障转移
|
|
446
|
+
- **资源管理**:通过智能调度实现高效的资源利用
|
|
447
|
+
|
|
448
|
+
## 🔍 监控和故障排除
|
|
449
|
+
|
|
450
|
+
### 要监控的关键指标
|
|
451
|
+
|
|
452
|
+
- **执行成功率**:成功任务执行的百分比
|
|
453
|
+
- **重试频率**:每个任务的重试次数
|
|
454
|
+
- **DLQ大小**:死信队列中的任务数量
|
|
455
|
+
- **执行时间**:任务完成的平均时间
|
|
456
|
+
- **调度准确性**:与预期执行时间的偏差
|
|
457
|
+
|
|
458
|
+
### 常见问题和解决方案
|
|
459
|
+
|
|
460
|
+
1. **高重试率**:检查网络连接和目标服务可用性
|
|
461
|
+
2. **DLQ溢出**:审查失败的任务并修复根本原因
|
|
462
|
+
3. **执行遗漏**:验证时区设置和调度表达式
|
|
463
|
+
4. **性能问题**:考虑对频繁任务使用delay-recur
|
|
464
|
+
5. **重复执行**:对适当的任务启用history_check
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@things-factory/scheduler",
|
|
3
|
-
"version": "9.0.
|
|
3
|
+
"version": "9.0.20",
|
|
4
4
|
"main": "dist-server/index.js",
|
|
5
5
|
"browser": "dist-client/index.js",
|
|
6
6
|
"things-factory": true,
|
|
@@ -29,9 +29,9 @@
|
|
|
29
29
|
"dependencies": {
|
|
30
30
|
"@operato/graphql": "^9.0.0",
|
|
31
31
|
"@operato/shell": "^9.0.0",
|
|
32
|
-
"@things-factory/auth-base": "^9.0.
|
|
33
|
-
"@things-factory/scheduler-client": "^9.0.
|
|
34
|
-
"@things-factory/shell": "^9.0.
|
|
32
|
+
"@things-factory/auth-base": "^9.0.20",
|
|
33
|
+
"@things-factory/scheduler-client": "^9.0.20",
|
|
34
|
+
"@things-factory/shell": "^9.0.20"
|
|
35
35
|
},
|
|
36
|
-
"gitHead": "
|
|
36
|
+
"gitHead": "d66d7047d01d82c6c676f8f02ecf1233fe55eaab"
|
|
37
37
|
}
|