最近有个项目里面需要用到消息通知，最开始的想法是用server酱类似的服务一个一个通知，最终没有选择server酱的原因是因为免费版本有消息数量限制，但是我们提供服务的群体并不能保证大家有针对server酱单独付费的意愿，所以在最初的版本里选择的server的替代品PushPlus，同样也是基于模板消息的推送。

因为我们的需求有一定的准实时性，后面提供的服务里面人数达到一定数量的时候，模板消息推送的劣势也体现了出来：高延迟。

按照消息推送的设计，肯定是做异步消息队列推送才能防止大规模调用导致资源的高占用，显而易见微信也不会让你高并发来个几千几万的发能实时到达的模板消息。

这就不得不思考怎么用新的方式进行消息推送，最理想的当然是在微信内进行推送，在V站搜索一翻找到了wechaty这个基于个人微信号的项目，跟到github上看，到现在还有在维护，所以就打算拿这个开搞。

wechaty这个项目提供了几种协议的机器人，除了web协议的其余的都收费，我最开始是拿web协议的进行搭建，关于封号的风险，根据描述说基本不会，实现的逻辑他们是基于无头浏览器进行HOOK操作的。不过17年以后的微信号是不用担心因为登录web微信封号的，因为17年以后的微信号根本就不支持web登录（大误。

捣鼓了半天总算docker把环境搭建出来了，正式运行后问题也开始出现了，频繁的会死掉，后面没办法就用go写了个程序监听逐行的wechaty控制台日志，凡是遇到了exception之类的关键字就进行容器重启，这样的话能尽量保证容器出现了异常情况会重启，但是遇到了重启的窗口期头新的会消息发送不了，因为消息需要及时性，所以重发的意义也不是很大。无头浏览器的内存占用是一言难尽的。

在使用web协议的机器人当中，还出现了消息延迟两分钟才收到，偶尔出现这个高延迟加上不定时的重启导致消息收不到，这个整个过程的体验是很差的，所以我觉得这只能算个勉强能用的方案，因为我的机器内存不是很大，无法测试在机器大内存情况下稳定性。

其实我是一直想尝试基于PAD协议的，但是入口是山路十八弯，隐藏得太深了，费死巴劲终于找到了基于PAD协议的申请入口，可以试用几天，进去注册，继续开整。

还是用docker跑，一顿操作下来结果还是grpc客户端连不上，也没有在控制台看到应该有的扫码登录提示，以为是docker镜像的问题，把镜像从wechaty:latest和wecahty:next反复试了好几遍，还是失败。我又尝试用他们官方提供的一键shell脚本，也还是不能用。

继续翻项目上的issue,总算找到了答案，参见这个issue:can't use gateway #117,还是镜像版本的问题，这个镜像wecahty:0.67这个标签的才行。

替换版本,docker-compose up -d，成功。

知道真相的我眼泪掉下来。

现在已经在稳定运行了三个多小时，内存占用稳定在200多M。

接下来如果能稳定运行几天的话，可以考虑付费了。