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

在前阵子我就现已接入了钉钉的群机器人和作业音讯推送，一向没写文章同步到给大家。

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

根据原有的架构上，感觉没啥技术性可言，关于新增发送途径这种需求也不会有代码的创新。所以，我一向不太积极干这事，但是，没人乐意干啊。

为了体系的完整性，我仍是花时刻去接入了。比如途径可发送不同的音讯类型（图片/markown/音频等等），根据不同的音讯类型或许我们要有素材办理相关的功用。

目前这种多类型的发送途径，因为我前端用的是低代码途径，在前端组装参数的时分不太灵活，但都一一克服了

所以，一个比较完整的音讯推送途径要干、要处理的作业仍是蛮多的，不要小看它。

能够到Git库房看看源代码，合作文章食用更加哟：

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

• gitee.com/zhongfuchen…
• github.com/ZhongFuChen…

01、群机器人

1、阅览官方文档：open.dingtalk.com/document/gr…

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

3、HTTP调用测验是否发送成功

02、钉钉作业音讯

1、在官网文档了解根底概念：open.dingtalk.com/document/or…

2、进入企业办理后台： open-dev.dingtalk.com/fe/app#/cor… ，随后创立应用

3、检查音讯通知发送的文档：open.dingtalk.com/document/or…

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

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

• gitee.com/zhongfuchen…
• github.com/ZhongFuChen…