「從模板訊息改版訂閱訊息」小程式推送
前言
只有光頭才能變強。
文字已收錄至我的GitHub精選文章，歡迎Star：https://github.com/ZhongFuCheng3y/3y
如果近期有看我文章的同學，會知道我最近在公司做的是推送系統。推送系統在我這也叫做訊息管理平臺，其實很容易理解：提供一個支援多渠道傳送訊息的系統。
在前段時間，微信公佈：小程式模板訊息介面將於2020年1月10日下線，開發者可使用訂閱訊息功能。
底層介面的變動，對程式設計師來說意味著什麼，你懂的。
人在家中坐，班從天上來
本篇文章主要來聊聊我這邊是怎麼傳送小程式訊息的，以及改版後的簡單介紹，希望對大家有幫助。
- 本文不涉及任何的高深知識，放心觀看。
一、前置知識
傳送小程式訊息其實很簡單，微信提供了微信官方文件供我們開發者去查閱相關的基礎知識，提供HTTP介面給我們去方便呼叫：
對開發者來說，傳送小程式訊息總結來說就三步：
- 在微信後臺建立模板
- 獲取下發的許可權
- 呼叫傳送介面，傳送訊息
無論是以前的模板訊息，還是現在新的訂閱訊息，步驟都是一樣的。
二、模板訊息和訂閱訊息的區別
為什麼微信要把模板訊息下線，要上線訂閱訊息呢？我們從傳送小程式的步驟來看，只有“獲取下發的許可權”是可動的，其餘的兩步都是相同的。
我們開發者要藉助微信平臺向用戶發訊息，需要一個理由(下發的許可權)。因為微信還是注重使用者體驗的。
2.1 模板訊息
模板訊息下發的理由是：使用者最近在小程式活躍過，有過互動的行為（比如說表單提交）。那麼開發者可以從這些互動行為中收集formId
一條formId會保留7天，當我們呼叫傳送介面的時候需要消耗一條formId。如果該使用者沒有formId的話，那麼我們則會發送失敗
- 重點：傳送模板訊息一定要攜帶
formId
說白了，這個formId就是使用者與小程式的互動憑證。微信認為：使用者最近使用過你的小程式，你才可以給他/她傳送訊息。
2.2 訂閱訊息
從模板訊息的下發理由我們可以發現：下發的權利是掌握在我們開發者手上的，只要我們通過使用者的各種行為收集到大量的formId，那我們在7天內就可以傳送多條訊息給到使用者。
訂閱訊息的下發理由是：把訊息是否推送的權利還給使用者。使用者來決定能不能收到推送，簡單來說就是：
- 當用戶觸發某些場景時，給使用者彈框，讓使用者決定是否收到推送（而且只會收到一次）
2.3 讓使用者收到自己想要的訊息
在最開始使用微信的時候，你可能還能收到一些營銷類的小程式通知，但近期你應該就收不到的。
- 不允許惡意誘導使用者進行觸發操作，以達到可向使用者下發模板目的
- 不允許惡意騷擾，下發對使用者造成騷擾的模板
- 不允許惡意營銷，下發營銷目的模板
標題不能涉及營銷相關內容，包括不限於：消費優惠類、購物返利類、商品更新類、優惠券類、代金券類、紅包類、會員卡類、積分類、活動類等營銷傾向通知
微信會檢測你的模板有無問題，如果有問題就會把你的模板給刪掉(當然了，也不讓你建立可能是營銷類的模板）。沒有了模板，消費就發不出去了。
總的來說：微信會通過各種方式來限制你的訊息下發，目的是想讓使用者收到他自己想要的訊息。這次將模板訊息改成訂閱訊息，更是把下發訊息的許可權交給使用者了。
至於這件是好事，還是壞事。不同人有不同的看法。
有的人會覺得：讓使用者選擇是否收到訊息，使用者所需要的操作就多了，彈窗也是對使用者的一種打擾。如果使用者不熟悉訂閱訊息或者直接點了“取消”，小程式就沒法通知到使用者了，使用者可能因此錯失服務，對商家和使用者都是損失。
有的人也會覺得：把推送訊息的權利掌握在使用者手裡，能很大程度上避免商家的惡意騷擾
對於此次的改版，可以在評論區下談談你的看法~
三、我們是怎麼做的？
我這邊來簡單說一下我這邊是怎麼接入推送小程式訊息的，希望對想要接入小程式訊息的同學有一定的幫助。
首先，針對在微信後臺建立的模板，我們是先把微信後臺的模板拉取到自己的資料庫儲存起來，然後再做一個管理頁面對模板進行管理。
如果某個訊息使用到了該模板，我們同樣也會做關聯起來（因為這樣可以方便查閱哪些訊息使用了這個模板）
- 正因為有了這個功能，所以我們這次遷移就可以很方便整理出目前還在使用的模板有哪些，使用的場景在哪。後續只要將訊息的模板ID改成訂閱訊息的模板ID就好了。
像我司不單單隻有一個小程式，所以要對小程式進行分類，這裡就不再贅述了。實際上就是封裝了一層，例如：蘑菇街女裝 標識為88，蘑菇街直播購物臺標識為 99
在設計和寫程式碼的時候要考慮後續的可擴充套件性
在模板訊息的時候，前端會打formId的點，我這邊會在Storm將MQ的資料清洗放到Redis裡邊。然後我這邊在傳送之前就判斷使用者有沒有對應的formId。
現在微信將模板訊息改為訂閱訊息，formId的收集到我這邊的Storm解析進Redis的操作都免去了。微信貌似也沒有提供介面給我判斷使用者是否有授權過。所以我只能在呼叫下發介面時，根據返回值來判斷使用者是否授權。
如果新接入微信小程式訊息的同學，那整塊流程就簡單很多了。
- 前端同學只要在必要的場景下彈窗，讓使用者授權
- 後端的同學直接下發到使用者，根據返回值判斷下發的情況。
所以，現在我這邊如果要下發一條訊息主要有兩個步驟：
- 在推送後臺新建一條訊息（選擇微信的模板、訊息建立者的基本資訊、訊息相關的規則處理（是否去重等等）
- 業務方呼叫我暴露的介面
業務方呼叫我這邊的暴露介面，我主要做以下的事情：
- 對業務方的傳入引數進行簡單的校驗，拼接成完整的一個模板訊息內容
- 如果業務方傳入的是
userId，我這邊需要轉為openId - 對訊息速度限流，呼叫微信的下發介面
除了訊息下發以後，我們還會考慮到訊息下發是否成功以及效果的問題（有無實時資料供檢視，有無離線報表分析），所以我這邊是這樣做的：
- 在關鍵的鏈路上進行打點
- 業務方呼叫我介面，我已經確認收到訊息了
- 這條訊息由於業務原因被過濾掉了（可能是userId轉openId失敗了）
- 在下發時可能由於模板/token/使用者無授權等等情況
- 將打點的資訊寫到Kafka，再由Storm清洗，實時的查詢的進Redis，離線的落到Hive表
這裡的打點實際上就是我們打日誌
比如下面是我實時推送後，根據userId查詢推送的情況：
最後
總的來說，小程式推送訊息並不難，也僅僅是幾個介面而已。現在改版為訂閱訊息後，那接入起來就更加方便了。再過一個月，你們使用小程式的時候可能就會收到各種的彈窗提醒你們是否要授權xxx模板訊息。
不知道大家看完我這篇文章有什麼看法，歡迎在評論區留言。我會經常分享我在工作中遇到的問題以及學習後精心整理後的筆記，希望對大家有所幫助，覺得我的文章還有點東西，不妨關注我！
本已收錄至我的GitHub精選文章，歡迎Star：https://github.com/ZhongFuCheng3y/3y
樂於輸出乾貨的Java技術公眾號：Java3y。公眾號內有300多篇原創技術文章、海量視訊資源、精美腦圖，關注即可獲取！
非常感謝人才們能看到這裡，如果這個文章寫得還不錯，覺得「三歪」我有點東西的話 求點贊 求關注️ 求分享