玩转钉钉消息推送！

我是3y，一年CRUD经验用十年的markdown程序员👨🏻‍💻常年被誉为职业八股文选手

在前阵子我就已经接入了钉钉的群机器人和工作消息推送，一直没写文章同步到给大家。

像这种接入渠道的工作，虽然我没接入过，但可预见性地就是看看官方文档，然后对着文档一顿学习，复制下接入的代码，然后调试，最后就完事了。老实说，有点枯燥。

基于原有的架构上，感觉没啥技术性可言，对于新增发送渠道这种需求也不会有代码的创新。所以，我一直不太积极干这事，但是，没人愿意干啊。

为了系统的完整性，我还是花时间去接入了。比如渠道可发送不同的消息类型（图片/markown/音频等等），基于不同的消息类型可能我们要有素材管理相关的功能。

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

所以，一个比较完整的消息推送平台要干、要解决的事情还是蛮多的，不要小看它。

可以到Git仓库看看源代码，配合文章食用更加哟：

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

01、群机器人

1、阅读官方文档：https://open.dingtalk.com/document/group/custom-robot-access

2、创建智能群助手，得到Webhook地址和加密的值

3、HTTP调用尝试是否发送成功

02、钉钉工作消息

1、在官网文档了解基础概念：https://open.dingtalk.com/document/org/basic-concepts

2、进入企业管理后台： https://open-dev.dingtalk.com/fe/app#/corp/app ，随后创建应用

3、查看消息通知发送的文档：https://open.dingtalk.com/document/orgapp-server/asynchronous-sending-of-enterprise-session-messages

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仓库地址：

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