我是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倉庫地址：
消息推送平臺🔥推送下發【郵件】【短信】【微信服務號】【微信小程序】【企業微信】【釘釘】等消息類型。