公众号模板消息与小程序模板消息

最近我司正在搭建微信方面的生态，其实微信生态说白了也就两个，公众号和小程序，但因为张小龙先生对小程序的期望是“用完即走，不粘人”，所以小程序要想主动触及到用户是有一定难度的，但是方法肯定是有的。

微信已经成了一个巨大的生态

首先声明：所有开发者都要严格遵守腾讯公众号和小程序的运营规范，不要做骚扰用户，违反规范的事情，不然可能会面临封号的结果。

纵观微信给的各种消息，我发现模板消息是很适合推送通知的一种形式，但不是所有的开发者都有模板消息的权限，并且根据用户量的不同，推送的消息数量也不相同，在官方文档里，说模板消息是需要用户主动触发的，我查了一些资料，发现有的说需要用户主动触发，有的说不需要，看来要想丰衣足食还得自己动手，于是我打开了 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 队列任务，然后其他的用法都是类似的。