xxl-job的一些感悟与规范

后台计划任务设计思路：

一一说来

日志埋点处理，便于prd排查问题

prd环境由于会受到严格管控，因此不可能让你idea直接连接jvm instance调试，一般来说，都是需要通过查数据或者查日志来看有没有执行，执行有没有报错，怎样的报错

也就是说此时的日志信息越完善越好，并且人类看了需要显而易懂，不需要倒腾来倒腾去，这样的日志信息给到的话，对开发人员来说是最友好的

因此埋点很重要，日志信息要详尽，越详尽越好，比如搜索出来的List size这些信息都要有，而不光是错误日志，记住越详尽越好，每个if/else节点的记录都要有

上面是记录，也就是日志埋点要想尽，但是人类需要interface才能查看到这些日志信息，因此日志的搜索也很重要，如：kibana等，因此针对kibana设计日志格式也很重要，日志记录时就要考虑到查看的友好性，不要日志记了，就是不好查。。。就麻烦了

也可以是日志记录归记录，中间加个处理切分丰富日志的表示环节也可以，到查看端能更易且更丰富的表现形式。

避免由于日志不详尽导致需要重新发布程序才能细化查问题现象出现。

2种主动job搭配规范（正向job、反查job）

当需要和三方系统做对接时，一般是我方get/post请求到对方系统，这个调用方式我称为正向调用

如果出现网络不通、或者对方系统正在发布而500报错了怎么办？

如果调用结果返回的是部分完成状态怎么办？比如我方系统把订单post到三方做业务，对方系统可能做了半同步半异步拆分，导致返回的业务状态为：部分完成。

而我们的系统依赖于这个业务返回完整完成状态后才能进行后续操作，同时我们也不想重复post订单到对方系统时，怎么办？

这时引入反查job，专门用来定时到对方系统查询业务最新状态（此时依赖对方系统有这种业务查询api供我方调用）

也就是写2个job，管你是否存在网络问题啥的，统统能考虑的到（对方系统api需要提供+自身状态机的流转（如网络不通时就不应该让反查job查了，因为根本还没有post订单过去））

1种消息接收的处理规范，重试机制，返回状态

有时，对方系统会主动通知业务的状况，可能是一次性的也可能是对方系统用了定时器定期推送的

此时，就需要和对方对应好是怎样的通知机制了，多次通知，可能需要做幂等

也可能约定好我方系统返回怎样的json内容，对方将终止推送等等

此时幂等必须要做了，因为从设计角度讲，总是需要将外部系统设定为不可靠系统对待。

job开关维度

大点的系统，job肯定是很多的，不同模块都好多job，有的会考虑把所有相关的job都合并起来处理

我说的合并是指1个job里，捞出一个大的List集合，然后分别foreach item，再循环内部判断这个item需要执行怎样的子job

当然上述是1个维度

还有个维度，就是尽量拆分子job到独立job里，单独变化，单独执行，要开要关都独立进行，没有job层面的依赖性（当然，数据层面必须会存在依赖先后顺序）

这个时候一般来说会拆分job，这样上了prd，会很方便的stop、start、临时execute某个具体job，不会说由于突发业务，或者突发异常，导致执行大job而产生一大堆job跑，或者说需要改数据才行，不太方便

job拆分后，很可能越拆越细，如果后续拆到独立docker中跑某几个job，大job就得改，麻烦

数据流图

job一多，其实对开发本身就越来越混淆了，再加上正向、反查job、工具job等，以及状态机这种依赖，确实需要设计图用来记录，帮助开发人员理解这些job

流程图（也包括跨系统的流程图）+数据流图

线上暗job-便捷性-工具job

其实上了生产环境后，很多时候系统还不太完善，有些小工具job还是要做的，比如红冲这种，可能需要做成job，并且要job能接收参数，要能临时红冲某笔订单等

这些其实很常见

处理流水表的设计

针对每笔业务的变动、每个三方api请求的参数、以及返回的response，都要记录到流水表中记录下来，这个和普通日志埋点又有区别

分布式多副本考虑

谁家的prd不是2副本以上？

因此得考虑job的并发问题、xxl-job能较好的解决并发问题，小概率的高并发在job层面不太多，实在出现了，就分布式锁搞定。

job其实水也挺深，但是有了最佳实践，就会好很多，你说呢

posted @ 2021-05-23 01:15 McKay 阅读(1032) 评论(0) 编辑收藏举报

刷新页面返回顶部