最近我司正在搭建微信方面的生态，其實微信生态說白了也就兩個，公衆号和小程序，但因為張小龍先生對小程序的期望是“用完即走，不粘人”，所以小程序要想主動觸及到用戶是有一定難度的，但是方法肯定是有的。

微信已經成了一個巨大的生态

首先聲明：所有開發者都要嚴格遵守騰訊公衆号和小程序的運營規範，不要做騷擾用戶，違反規範的事情，不然可能會面臨封号的結果。

縱觀微信給的各種消息，我發現模闆消息是很适合推送通知的一種形式，但不是所有的開發者都有模闆消息的權限，并且根據用戶量的不同，推送的消息數量也不相同，在官方文檔裡，說模闆消息是需要用戶主動觸發的，我查了一些資料，發現有的說需要用戶主動觸發，有的說不需要，看來要想豐衣足食還得自己動手，于是我打開了 postman（一款用于調試API的神器）填上了 access_token,填上了需要 post 的數據，發現可以發送，并且可以重複發送，我試了很多次都可以成功，所以我還沒有試出模闆消息對單個用戶推送的上限，再次重申：請嚴格按照微信的運營要求。接下來就是小程序的模闆消息，這個是真的需要用戶主動觸發的，要麼是表單提交行為，要麼是支付行為，那這麼說小程序無法主動下發消息了嗎，還是那句話，方法肯定是有的，但是需要前端配合，前端需要修改頁面元素，把普通元素僞裝成表單元素，然後用戶的普通點擊行為就産生了用于發送模闆消息的 form_id ，然後提供一個專用的接口給前端，把收集的 form_id 傳回後端。

我這邊大概講一下整體，首先會有一個 rpc 服務，用于記錄用戶的 member_id（用戶在你們内部的唯一标示）與 open_id ，通過傳入 member_id 和 不同的公衆号或者小程序的 app_key 就可以獲得對應的 open_id，因為這些是很基本的東西，然後我用了 redis 來維護 member_id 和 form_id 之間的關系，redis 的 key 是和 member_id 相關的，所以可以通過 member_id 來獲取 form_id ,并且我是選擇了 list 這種結構來存儲的，lpush 和 rpop,先進先出，因為 form_id 是有七天時效性的，所以需要使用隊列的用法。基礎服務搭好以後就是構建上層服務了，首先有一個續費通知，提醒用戶提前續費，因為這是一個批量查詢的腳本任務，所以我沒有新增 rpc 接口，而是查詢付費服務的離線庫，每天定時執行腳本任務，值得一提的是在發送每一個消息之前會檢查是否有發送資格，我這邊資格暫且是這麼定的，一天最多一次，一周最多三次，然後把要發送的任務加到一個 miller 任務隊列裡面，它其實是一個 beanstalk 隊列任務，然後其他的用法都是類似的。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!