1年后,終于要上線了呀!
我的開源項目消息推送平臺Austin終于要上線了，迎來在線演示的第一版！
??項目在線演示地址：http://139.9.73.20:3000/
不得不說，為了這個「在線演示」我前期做了很多工作：
1、渠道賬號配置改為在前端上做頁面管理，之前會把渠道的賬號配置散落在分布式配置中心/本地配置文件；
2、使用docker-compose部署后端項目，預(yù)料到后續(xù)迭代頻繁，需要有簡單且好用的部署姿勢；
3、做簡單的用戶登錄功能，在線演示的系統(tǒng)每個用戶只能看到自身賬號的信息，用戶之間不共享信息；
4、充錢買服務(wù)器，現(xiàn)有我調(diào)試的服務(wù)器配置不夠，只能買新的服務(wù)器；
借著這個開心的日子，我順便把使用的姿勢也更新了一把。
使用姿勢
1、創(chuàng)建需要發(fā)送的渠道賬號
2、創(chuàng)建消息模板
3、測試發(fā)送消息是否正常
4、查看消息下發(fā)情況
5、亦可在新建模板時選擇定時任務(wù)，通過上傳csv文件和指定cron表達(dá)式實現(xiàn)下發(fā)消息
微信掃碼登錄實現(xiàn)
這幾天我做的就是用docker-compose部署項目不斷地調(diào)試，以及把「用戶登錄」功能給實現(xiàn)了。
我在生產(chǎn)環(huán)境下是沒有寫過「用戶登錄」的，導(dǎo)致有些業(yè)務(wù)功能我也不知道線上是怎么實現(xiàn)的。而「用戶登錄注冊」這個功能之前會聽過和見識過一些技術(shù)棧「Shiro」、「JWT」、「Spring Security」、「CAS」、「OAuth2.0」等等。
但是，我的需求只是用來做簡單的校驗，不需要那么復(fù)雜。如果就給我設(shè)計一張user表，對其簡單的增刪改查好像也滿足，但我又不想寫這樣的代碼，因為我在大學(xué)的時候?qū)崿F(xiàn)過類似的。
現(xiàn)在不都流行掃碼登錄嘛？我不是已經(jīng)接入了微信服務(wù)號的模板消息了嗎，不正好有一個測試號給我去做嗎？于是就開干了。
首先看看人家是怎么寫的，于是被我找到了一篇博客：https://blog.51cto.com/cxhit/4924932
過程挺好懂的，就按著他給出的時序圖對著實現(xiàn)就完了。后端對我來說實現(xiàn)并不難，花的時間最長的還是在前端的交互上。畢竟我這當(dāng)時選用的是低代碼平臺啊，不能隨便實現(xiàn)各種邏輯的啊。
在前端，就一個「輪詢」功能，要輪詢查看用戶是否已經(jīng)訂閱登錄，就耗費(fèi)了我很多時間在官方文檔上。后來，寫了不少的奇淫技巧，最后也就被我實現(xiàn)出來了。實現(xiàn)過程很糟糕，也不值一提，反正你們也不會從中學(xué)到什么好東西，因為我也沒有。
過程還是簡單復(fù)述下吧，后期可能也會有同學(xué)去實現(xiàn)這個功能。
1、首先我們要有一個接口，給到微信回調(diào)，所以我們一般會稱該接口為回調(diào)接口。微信的一些重要的事件都會回調(diào)給我們，我們做響應(yīng)的邏輯處理。就比如，用戶關(guān)注了服務(wù)號，這種消息微信就調(diào)用我們的接口。
2、在微信后臺配置我們的定義好的回調(diào)接口，給到微信進(jìn)行回調(diào)。
（如果接口是通的，按正常的走，那就會配置成功）
3、編寫一個獲取微信帶參數(shù)的二維碼給到前端做展示。
4、前端拿到二維碼做展示，并且得到隨機(jī)生成的參數(shù)輪詢查看是否已登錄。
5、編寫檢查是否已登錄的接口給到前端進(jìn)行判斷。（如果能從Redis里拿到隨機(jī)參數(shù)，說明已經(jīng)登錄了）
6、當(dāng)用戶掃碼關(guān)注了服務(wù)號，則得到微信的回調(diào)。當(dāng)用戶關(guān)注服務(wù)號時，會把隨機(jī)參數(shù)和openId傳給服務(wù)器，我則將信息存入Redis。
7、前端得知已登錄后，將用戶信息寫入localStorage
推薦項目
如果想學(xué)Java項目的，我還是
強(qiáng)烈推薦
我的開源項目消息推送平臺Austin，可以用作
畢業(yè)設(shè)計
，可以用作
校招
，可以看看
生產(chǎn)環(huán)境是怎么推送消息
的。
倉庫地址（可點擊閱讀原文跳轉(zhuǎn)）：https://gitee.com/zhongfucheng/austin
我開通了 股東服務(wù) 內(nèi)容，感興趣可以點擊下方看看，主要針對的是項目喲