有点枯燥-技术圈

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

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

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

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

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

目前这种多类型的发送渠道，由于我前端用的是低代码平台，在前端组装参数的时候不太灵活，这块后续还得解决。

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

01、群机器人

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

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

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

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都会有限制调用频率的，没过期的前提下也没必要去调用外界的接口取）

分析后，依我看来，就两种思路：

我一想，肯定是定时任务刷新比较合适啊，反正我已经接入了xxl-job了，新增一个定时任务不就完事了？

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

最近在规划的东西还是蛮多的：

1、做austin的视频教程，以至于提高austin消息推送系统的影响力

2、在项目中引入单元测试框架，编写一些单测代码以便调试

3、引入工作流引擎实现消息审核的功能

4、多接入几个渠道：包括但不限于服务号、小程序、push通知栏。这些都有一定的门槛（需要app或营业执照)，丰富平台的能力。

5、austin项目付费服务

其实这几个点我都有在看和付出了实际的行动（但真正落地的还没有）；

1、视频课程对我来说确实有点难，我一直想干但是干不下去的边缘徘徊中，我还是希望我能迈出第一步的。我已经久违下载好的软件重新打开了，录制的快捷键也回想起来了。

2、我问过大厂朋友他们的单测是怎么写的，有没有必要写，单元测试是向上管理工程还是真的有必要，单元测试的基础知识也看了些；

3、工作流引擎也看了下现在Java开源的技术选型应该哪一个，也补充了这方面的基础知识（所以可以看到前两天我分享了一篇工作流引擎的文章）；基于对现状的考虑，这块优先级我已经调至很低了。

4、...

5、有计划并付出实践中...

目前austin交流群还有些名额，如果想进群的小伙伴可以添加我的个人微信备注『项目』，我空的时候会统一拉进群。

阅读原文可跳转至Austin仓库获取源码