Skip to content

Latest commit

 

History

History
192 lines (137 loc) · 7.45 KB

protocol.md

File metadata and controls

192 lines (137 loc) · 7.45 KB

协议

这里列出了各个中间件在通讯传递过程中的协议细节，协议本身采用JSON传递，根据不同的字段实现不同的协议功能

Trigger

前端触发器的任务列表，触发器会在一个特定周期内读取一次触发任务，并执行满足触发条件的任务以实现周期性任务生成

规则引擎允许在函数触发器前先执行若干SQL语句，稍后便会将返回数据一同携带至目标触发函数

警告：规则引擎不会检查即将执行的语句是否会对目标数据库造成影响，或者对返回执行错误的结果进行特殊处理，若因SQL语句执行错误，会导致受影响的目标任务被跳过无法触发

任务是以JSON字符串形式在Redis中以键为FrontEndTrigger.trigger的数据结构(hash)

key:

任务名，可任取

values:

{
    "cron": "*/30 * * * *",
    "trigger": "bangumi",
    "rules": []
}
keys values
cron Cron时间语句，单位分、时、日、月、周
trigger 触发推送函数
rules 规则引擎推送数据SQL，可使用多条SQL进行连续多次查询(可选) 可选不是空，是空数组

运行过程中，可以随时修改任务信息，会在10秒内自动生效

Event

由各中间件按照下述格式生成事件之后交由并发中心进行任务调度

具体实现参见bilicenter_middleware/event.py

{
    "eid": "61e16ac3-76bd-524d-a897-60b1d16de18e",
    "source": "0102",
    "attach": {},
    "scf": true,
    "job": {},
    "event_timestamp": 1615856135
}
keys values
eid 唯一事件ID
source 事件发起的中间件
attach 事件附加信息，会原样带入事件回调信息中(数据类型强制为dict)
scf 是否为SCF任务，决定是否要将事件转换为SCF任务并部署，不为SCF任务时将直接回调
job Jobs 详见下述内容
event_timestamp 事件生成的时间

Jobs

并发中心接收并部署任务的交换格式，一般情况下不需要手动构建，以下内容仅作为参数说明，便于在以下的事件回调信息的job参数中提取数据。在构造数据时，只需要使用相关中间件封装的工具方法即可

实现参见bilicenter_middleware/event2job.py

{
    "function_name": "biliHelper",
    "namespace": "crawler",
    "qualifier": "$LATEST",
    "data": {
        "job_key": "biliCenter.bangumi.meta",
        "kwargs": {
            "arg_key": "arg_value"
        }
    }
}
keys values
function_name SCF函数名(工具方法会从配置的环境变量自动读取)
namespace SCF命名空间(工具方法会从配置的环境变量自动读取)
qualifier SCF执行目标版本(工具方法会从配置的环境变量自动读取并配置默认值)
data SCF传递数据

任务部署

并发中心将任务部署至分布式SCF时具体传递的数据，同样也无需手动干预

{
    "job_key": "biliCenter.bangumi.meta",
    "kwargs": {
        "arg_key": "arg_value"
    }
}
keys values
job_key 任务统一化键，定义任务时指定
kwargs 传递给任务的参数

事件回调信息

有些属性实际上是上方Event中的数据

{
    "code": 200,
    "msg": "ok",
    "rid": "9ac005ada66a1c454ab0c0cbf40d7eaf",
    "source": "0102",
    "eid": "f85a307e-656d-5e18-a413-1b3419e829c2",
    "attach": {},
    "data": {},
    "job": {},
    "event_timestamp": 1615856135,
    "callback_timestamp": 1615856249
}
keys values
code 任务执行返回码，非SCF任务时固定200
msg 任务执行结果信息，非SCF任务时固定"ok"
rid 标志本次部署SCF任务的request_id
source 事件发起的中间件
eid 事件ID
attach 事件附加信息
data 任务结构负载，即本次任务的执行结果
scf 是否为SCF任务，非SCF时某些字段为空内容
job 本次任务信息，详见上方jobs
event_timestamp 事件生成时间
callback_timestamp 回调生成时间

事件处理规则

一般情况下，并发中心接收一个事件请求，便立即将其放入调度队列，以供执行，若正常执行成功，则正常返回数据

若执行返回数据提示异常，则进行以下判断：

  • 接口返回412，提示访问被封禁，或返回500，提示信息解析过程中错误，并发中心将会发起总共三次重试，只要请求成功则回调正常数据，直到重试结束仍未成功，回调最后一次失败数据，并同时将回调数据放入死信队列，放弃尝试
  • 接口返回非412和500，不再做后续尝试，直接将此次结果推送至回调中心，并记录至警告日志[SCF code]
  • 从返回中读到stackTrace信息，提示分布式SCF侧发生未捕获异常，同样为重试三次
  • 云函数SDK请求异常，会持续进行重试，并记录至警告日志[SCF SDK error]
  • 并发中心会监测死信队列和警告日志情况，并在必要时推送提醒信息

Logs

是存储在Redis当中用于记录各中间件运行过程中的值得注意的警告信息，在达到一定阈值后将会触发提醒信息推送，具体到Redis中的键为logs的数据结构为列表(list)

{
    "timestamp": 1613306578,
    "msg_type": "SCF 404",
    "content": {
        "event": {},
        "msg": "xxxxx"
    }
}
keys values
timestamp 日志记录时间戳
msg_type 消息类型
content 具体消息的负载，不同消息的负载结构有所不同

Dead Letter

死信队列是一个需要非常关注的区域，这个区域存放了并发中心在部署任务时，最终因为某种原因导致失败的事件回调消息，会详细记录时间发生的时间与相关信息便于问题定位，出于稳定性和事件完整性考虑，一旦死信队列存在内容，会立即触发提醒消息推送。具体到Redis中的键为dead_letter的数据结构为列表(list)

死信队列中的数据结构同事件回调信息一致