基于Spring Cloud的全自动化微信公众号消息采集系统-PC端采集列表

前言

前面两篇文章介绍了系统流程和功能模块的封装，这篇文章将对消息列表的采集做以说明，此篇文章中注重思路而不是技术和源码，逻辑的代码千篇一律，可靠的算法万里挑一。

准备工作

1、采集来源

研究发现公众号文章访问获取的渠道有多种：

• 搜狗搜索：只能获取前10条；
  

• 公众号历史消息页，24H内公众号有次数限制（目前发现200+次数，不同微信号可能有所不同）；
  

• 微信公众平台写图文消息引用其他公众号文章的查询接口，频繁后会限制查询；
  
  经需求分析后，最终选用了第二种方式，可通过多微信号避免超过限制次数。访问历史消息页面在普通浏览器打不开，直接转到谷歌浏览器中缺少参数，通过Fiddler对请求进行分析，实际的请求链接有很多参数，把抓包的链接放到谷歌浏览器中可以正常打开，默认有第一页的数据，向下滑动后异步加载第二页。对分页查询的接口进行分析发现请求的参数和页面上的参数除了页码都是一样的，自己拼装完分页链接可直接查询任意页的数据，所以最终确定的思路是：微信浏览器跳转到历史消息页，fidller截取请求，将完整链接提交到自己的服务器，然后将链接中的参数提取出来，自己数据库配置每个公众号每次翻多少页和获取某个时间点之前的数据，整合参数和定制配置组装成分页查询链接通过HttpClient发送请求，然后解析返回数据保存。

2、页面跳转

上一小节介绍了数据的来源和请求方式，但是不能每次都人工去点，这样就失去了自动化的意义，最终目的是做到自动跳转。一般有两种思路：

• 自动化脚本模拟点击
• 代理工具js注入

js注入方式占用资源少，模拟点击有很多限制，比如点击页面必须在最上层等等，最终选择了js注入方式，代理工具也有多种选择，因为没有太复杂的需求，这次选择的是轻便的Fiddler，没有使用过的读者可自行百度，傻瓜式安装完后再安装证书即可，拦截历史消息页的请求，在将页面返回给浏览器之前，在返回的内容中加入一段简单的js代码，控制页面在10s后跳转到自己服务器的页面，其实这一步也可以直接加入js代码去自己服务器请求任务直接跳转到下一个公众号历史消息页，但是为了灵活控制频率和查看实时进度建立了一个中间页面，历史消息页完成后直接跳转到中间页面，中间页面去后台获取新的任务一定时间后再跳转到历史消息页面，依次循环。
由于集群部署，将页面放在了nginx中，同时也解决了跨域问题。

3、任务队列

前面一直提获取任务、执行任务，读者可能还不清晰任务是一个什么样的数据结构，其实很简单就是一个队列，存的是公众号的一个参数biz，有了这个参数就可以拼装公众号历史消息页：http://mp.weixin.qq.com/s?__biz=xxx。由于是分布式集群部署，选用的是redis队列，每次请求pop出一个biz，可通过redis的单线程特性避免重复执行任务。

4、任务监听

前面工作做完后其实就可以自动不停地执行任务了，但是任务不是24H不停的执行，当任务队列为空时，循环就停止了，但是下一次任务又进入了队列，前端页面需要再次去获取任务，解决这问题最便捷的方式显然就是长连接，定时请求也可以只是比较耗费资源并稍有延迟，新版Nginx对websocket支持也很友好。
当任务完成后，页面随机和后台一个节点建立长连接，任务再一次进入队列的同时，要通过RocketMq发一个广播消息，通知到集群中的每一个节点，节点收到广播消息后，通知所有和自己建立长连接的页面去获取任务，进入循环。

核心流程

明人不说暗话，先上图：

1：可以在多台主机登录多个微信，同时去访问中间页面；
1.1：去后台请求任务，有任务的话就去循环执行，没任务就去建立长连接；
2：页面随机跟后台一个节点建立长连接；
3：任务入队列，rocketmq发送一个广播，通知到集群中的每个节点；
4：节点收到广播消息后在通过长连接给页面发消息；
5：页面收到消息后，去后台请求一个任务，和1.1一样；
6：访问历史消息页，此处有坑，此处有坑，此处有坑，直接location跳转会失败，还是参数不全，要把链接填充到页面一个超链接中，并且超链接的target不能为self，然后js模拟点击此超链接才能跳转；
7：Fiddler将带参数的链接传给后台；
7.1：在将页面返回给浏览器之前注入自动跳转的js，页面定时跳转到中间页面；
7.2：后台获取参数后，根据自己对公众号的自定义配置，组装成分页查询链接，通过HttpClient请求，解析返回的Json数据存库；
8：页面跳转了回来重新执行1.1，依次循环。

附加功能

账号访问控制

因为腾讯对每个账号24H内可访问历史消息页分页查询接口有限制，为了避免账号封号，对每个手机号访问时间进行了记录，存储结构也是redis队列，每个手机号加上指定前缀为key，每访问一页就把当前时间戳push到当前手机号对应的队列。

• 在核心流程第一步访问页面的时候加上自己手机号参数，页面拿到手机号参数后先去redis中查询当前key对应的队列，查看队头元素转换成时间到目前是否超过24H，超过就删除直到没超过24H或者队列为空为止，然后判断队列长度，如果超了限制页面就定时2分钟后再次访问，当没有超过限制就进行接下来的流程，限制阈值大小根据实际情况而定。
• 核心流程第六步跳转的时候在链接上多加一个手机号参数再进行跳转。
• 核心步骤7会把手机号参数传给后台，7.2获取到手机号参数后每访问一页就把当前时间存入到手机号对应队列的队尾。
• 核心步骤7.1也会获取到手机号参数，再跳转到中间页面的时候再把手机号参数加进去。

这样下来，页面上会实时显示当前手机号和当前账号24H内已经执行的次数。

访问频率控制

为了防止封号，要加入睡眠调控访问的频率，但是任务多并且账号充足时可能需要提高一下访问频率。
核心流程第五步获取任务之前先去后台random一个睡眠时间，睡眠时间的最小值和最大值在nacos的配置中心中设置，获取时间后页面定时指定时间后再去执行接下来的流程，这样就可以通过nacos的热配置功能实现不重启项目的前提下改变访问频率。

总结

到此为止已经获取到了文章的基本信息，此时还没有正文和互动量，项目的第一个核心点已经完成，相对互动量来说逻辑不是很复杂，后面将再讲解互动量和正文的获取流程和一些巨坑，原创不易，希望老铁们手里的小赞不要吝啬走一走，感觉有帮助的朋友可以给个收藏关注。

本系列文章纯属技术分享，不作为任何商业用途，如若转载，请注明出处。