乐趣区

关于后端:搞掂钉钉消息推送

我是 3y,一年 CRUD 教训用十年的 markdown 程序员👨🏻‍💻长年被誉为职业八股文选手

在前阵子我就曾经接入了钉钉的 群机器人 工作音讯 推送,始终没写文章同步到给大家。

像这种接入渠道的工作,尽管我没接入过,但 可预见性地 就是看看官网文档,而后对着文档一顿学习,复制下接入的代码,而后调试,最初就完事了。诚实说,有点干燥

基于原有的架构上,感觉没啥技术性可言,对于新增发送渠道这种需要也不会有代码的翻新。所以,我始终不太踊跃干这事,然而,没人违心干啊

为了零碎的完整性,我还是花工夫去接入了。比方渠道可发送不同的音讯类型(图片 /markown/ 音频等等),基于不同的音讯类型可能咱们要有 素材治理 相干的性能。

目前这种多类型的发送渠道,因为我前端用的是 低代码平台,在前端组装参数的时候不太灵便,但都一一克服了

所以,一个比拟残缺的音讯推送平台 要干、要解决 的事件还是蛮多的,不要小看它。

能够到 Git 仓库看看源代码,配合文章食用 更加哟:

音讯推送平台🔥推送下发【邮件】【短信】【微信服务号】【微信小程序】【企业微信】【钉钉】等音讯类型

  • https://gitee.com/zhongfuchen…
  • https://github.com/ZhongFuChe…

01、群机器人

1、浏览官网文档:https://open.dingtalk.com/doc…

2、创立智能群助手,失去 Webhook 地址加密的值

3、HTTP 调用尝试是否发送胜利

02、钉钉工作音讯

1、在官网文档理解根底概念:https://open.dingtalk.com/doc…

2、进入企业治理后盾:https://open-dev.dingtalk.com…,随后创立利用

3、查看音讯告诉发送的文档:https://open.dingtalk.com/doc…

4、间接引入钉钉的 SDK 开发(次要是不便后续其余的操作,SDK 会比 HTTP 不便不少)

5、对于拼装参数调用工作音讯接口,没什么好值得说的,大家把代码拉下来就看得一清二楚了。

6、从文档发现调用接口须要 access_token 这个参数,还发现这个参数是会过期的( 2 个小时

有了这个 access_token 参数之后,咱们就须要思考怎么去“保护”它,毕竟它会过期的,不能当做一个动态参数写死在代码或者配置文件上。

我过后是发这个问题到小群里,看看大伙们都是怎么“保护”的。毕竟,咱们不可能每次在调用接口的时候都去近程拿到最新的(个别内部的 API 都会有限度调用频率的,没过期的前提下也没必要去调用外界的接口取)

剖析后,依我看来,就两种思路:

  • 定时工作刷新,每隔一段 工夫去获取最新的access_token,将最新的 token 凋谢接口给有须要的人应用。
  • 调用接口的时候拿到上一次的 access_token,如果发现access_token 生效了再 从新获取并重试接口

我一想,必定是定时工作刷新比拟适合啊,反正我曾经接入了 xxl-job 了,新增一个定时工作不就完事了?

不过也有小伙伴说他们是第二种思路,如果发现 access_token 生效了,再从新获取并重试接口。我让他们来聊下为什么要这么干的时候,他们也说不出个所以然。(懂的老哥能够在评论区交换交换

03、反对撤回和多种类型音讯

在这个过程中,有的同学会给我留言,会问我是不是 音讯类型设计 得有问题,只反对 文本类型 的:

其实并不是,在之前的文章提到了,接入渠道其实 是个很干燥 的过程,很苦逼 的过程。既然都被说到了,没方法,卷了几天把 钉钉渠道 群机器人 工作音讯 官网所反对的 所有音讯类型 都给写了。

又因为工作音讯可能会发图片 / 语音 / 文件这种音讯类型,而这些的音讯类型须要把素材先发到钉钉,能力进行音讯下发,所以我这边也曾经写了 素材上传的模块

在后端实现上,这块代码量并不大,因为整个架构都根本写好了,只有适配下参数调用接口下发就完事了,花了一周左右工夫都在前端上了(:

前端要做联动,要依据不同的渠道不同的音讯类型提交不同的参数格局到 Java 接口,真的写死我了。不过,逐步把音讯推送平台的功能完善,看到 stars 也在一直的晋升,感觉还是不错的。

代码写得比拟多的其实是在 钉钉利用工作音讯撤回 这个性能上,在最开始设计接入层代码的时候,我用的是 责任链设计模式 。那时候我曾经预留了可能会有某些申请走不同的责任链,所以会有code 这个参数

/**
 * 发送 / 撤回接口的参数
 * @author 3y
 */
@Data
@Accessors(chain = true)
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class SendRequest {
​
    /**
     * 执行业务类型
     * send: 发送音讯
     * recall: 撤回音讯
     */
    private String code;
​
    /**
     * 音讯模板 Id
     *【必填】*/
    private Long messageTemplateId;
​
​
    /**
     * 音讯相干的参数
     * 当业务类型为 "send",必传
     */
    private MessageParam messageParam;
    
}

而对于音讯撤回而言其实就是 复用了 责任链的其中两个节点,没有一般音讯下发时的参数校验逻辑;后续其余渠道的音讯撤回如果变动不大,则在这些节点上扩大。如果变动比拟大,可能就要独自新增对应的责任链节点做对立的解决比拟适合了。

    /**
     * pipeline 流程控制器
     * 后续扩大则加 BusinessCode 和 ProcessTemplate
     * @return
     */
    @Bean
    public ProcessController processController() {ProcessController processController = new ProcessController();
        Map<String, ProcessTemplate> templateConfig = new HashMap<>(4);
        templateConfig.put(BusinessCode.COMMON_SEND.getCode(), commonSendTemplate());
        templateConfig.put(BusinessCode.RECALL.getCode(), recallMessageTemplate());
        processController.setTemplateConfig(templateConfig);
        return processController;
    }

举荐我的项目

如果想学 Java 我的项目的,我还是 强烈推荐 我的开源我的项目音讯推送平台 Austin,能够用作 毕业设计 ,能够用作 校招 ,能够看看 生产环境是怎么推送音讯 的。

开源我的项目音讯推送平台 austin 仓库地址:

音讯推送平台🔥推送下发【邮件】【短信】【微信服务号】【微信小程序】【企业微信】【钉钉】等音讯类型

  • https://gitee.com/zhongfuchen…
  • https://github.com/ZhongFuChe…
退出移动版