共计 2922 个字符，预计需要花费 8 分钟才能阅读完成。
我是 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…
