我是3y，一年CRUD經驗用十年的markdown程式設計師???常年被譽為職業八股文選手
在前陣子我就已經接入了釘釘的群機器人和工作訊息推送，一直沒寫文章同步到給大家。
像這種接入渠道的工作，雖然我沒接入過，但可預見性地就是看看官方文件，然後對著文件一頓學習，複製下接入的程式碼，然後除錯，最後就完事了。老實說，有點枯燥。
基於原有的架構上，感覺沒啥技術性可言，對於新增傳送渠道這種需求也不會有程式碼的創新。所以，我一直不太積極幹這事，但是，沒人願意幹啊。
為了系統的完整性，我還是花時間去接入了。比如渠道可傳送不同的訊息型別（圖片/markown/音訊等等），基於不同的訊息型別可能我們要有素材管理相關的功能。
目前這種多型別的傳送渠道，由於我前端用的是低程式碼平臺，在前端組裝引數的時候不太靈活，但都一一克服了
所以，一個比較完整的訊息推送平臺要幹、要解決的事情還是蠻多的，不要小看它。
可以到Git倉庫看看原始碼，配合文章食用更加喲：
訊息推送平臺?推送下發【郵件】【簡訊】【微信服務號】【微信小程式】【企業微信】【釘釘】等訊息型別。
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倉庫地址：
訊息推送平臺?推送下發【郵件】【簡訊】【微信服務號】【微信小程式】【企業微信】【釘釘】等訊息型別。