你好,我是DS Hunter。
前面12讲,我们讲完了反爬虫的所有操作,但是你可能会觉得,这样一攻一防的讲解在应用的时候会存在割裂感,实际工作中,还是摸不透反爬虫的整个流程。
那么今天,我就带你完整地走一遍反爬虫流程,从信息收集开始,到对爬虫的预估、线上测试,对工作需求的分析,最后,也会告诉你在流程中存在的风险点。
希望你能够通过今天的课程,理解那些反爬虫里严肃的纯理论知识。甚至,你可以把今天的课程当作反爬的标准流程手册。当然,我更希望你能通过今天的总结,了解反爬虫到底反的是什么。是爬虫,还是商业竞争?
在课程开始之前,我推荐你点开这一讲的音频,可以说,和课程的风格是完全的AB两面,至于如何不同,就等你点开来听了。
首先,我们回顾一下爬虫反爬虫的基础理论。我在上一讲提到过,当你不知道采用什么样的手段反爬的时候,回归初心,往往能够帮助你出奇制胜。
有的时候,你的反爬可能真的是因为竞对,也可能这就是一个因为技术界轮子太多,不得不另辟蹊径、完成目标的一个选择。你可以想想:
一个阴霾的晚上,伸手不见五指,你和你的Leader,在一家小龙虾店聊工作。- - 你的领导剥着小龙虾,对你说:“又一个双月要过去了,我们什么轮子也没造,下个月的目标恐怕不好写啊。”- - 你思考了一下,和领导说:“领导,不如我们另辟蹊径,选一个非主流的方向,我们造个反爬虫的轮子如何?爬虫就是大家说的抓取啊,嚣张点,起个TCP链接直接干到对方服务器上,把数据都拉下来就行了,反爬虫就是,别人拉我们数据,我们就干他,让他敢这么嚣张。”
那么,接下来我们在向上对齐的时候就需要有一个看起来官方一点的、正式的定义。我们来复习一下。
是的,这些定义完善又好理解。换句话说,我们常说的反爬虫要做的就是基于分布式平台下的数据加密保护。而且,在反爬虫开始前,我们一定要明确,那就是爬虫和反爬虫从来不计较一次两次的请求得失,甚至有意会放过对方来达到一些迷惑效果。
爬虫与反爬虫的博弈,是一种针对批量数据进行斗智斗勇的游戏,其中反爬虫需要在尽可能保持高拦截与低误伤率的要求下进行。这种博弈以资源消耗为战争手段,以商业优势为最终目标。
在明确了我们的最终目标之后,实际上,我们要做的第一件事就是收集信息了。信息收集是反爬虫的基石,完成了这一步,才能开始后续的所有操作。
反爬虫信息收集,指的是通过前端辅助,或者通过http请求信息,获取用户信息,用于后续分析判定的一种行为。该信息可能直接被加密上传,也可能被提取特征后上传。
这时候的你,已经明白信息收集的意义了。接下来咱们就来走一遍信息收集的过程。我们都知道,前后端都可以收集信息,那到底收集什么信息呢?
这里,我将反爬虫信息收集的类型分为三类:前端辅助信息、HTTP请求信息收集以及两者辅助同时收集。
针对第一类,我们主要的收集手段是使用js代码,提取浏览器特征或者业务特征。具体操作方式包括Canvas指纹以及DOM指纹,或者定制化特征提取。
针对第二类HTTP请求信息,我们可以通过分析HTTP Header信息来进行规则提取,并经由规则引擎分析,进行处理。
那么最后一类,可能相对复杂一些。我们需要通过查找js特征与HTTP Header的关联关系,并针对这种关系进行分析。例如客户端的location.href与Ajax的referrer,应该有匹配关系。这些关系都可以成为监测点。
看起来,我们的信息收集已经完整、可行了。不过只收集信息,不能产生信息反哺回系统,似乎也不够闭环,也会出现被质疑的情况。那么不论出于什么样的目的,是打破质疑还是验证反爬效果,我们都需要收集埋点信息让整个反爬形成闭环。
反爬虫埋点,其实就是由反爬虫系统产生,可以用于验证反爬虫系统效果的数据。我们通常将这里的数据分为三类:
第一类,经由反爬虫系统分析后得出的“是否为爬虫”标记。- 第二类,爬虫的特征,如类型,来源,数量,等等。- 第三类,测试策略的线上检测效果数据。
当然,根据埋点收集方式,埋点又可以分为前端埋点与后端埋点,前端埋点由前端进行收集,后端埋点由后端独立进行收集。
通常来说,“是否为爬虫”标记,在后端可以独立进行收集,尽可能不要过前端,因为前端没有秘密,过前端等于告诉爬虫自己是否中招。而第二类爬虫特征的采集,不关注采集途径。不过如果来自前端,则需要适当加密。测试策略线上检测效果,我们一会谈到“反爬虫线上策略测试理论”的时候,会详细展开。
接下来我们面对的问题,就是给拦截的成果定性定量了。你要知道,反爬基本是在明处的,而爬虫在暗处,如果我们也不知道自己拦截了多少爬虫,这样看起来一拍脑袋就决定了的规划送上去,要直接被拍死的就是自己了。
所以,我们需要一个可以定量衡量的指标。
反爬虫的衡量指标,主要在于拦截率以及误伤率。这两点都需要预估线上爬虫量,才能进行估算。这里,给你提供两个公式。
拦截率=拦截掉的爬虫/线上爬虫总数。
拦截掉的爬虫等于:拦截爬虫量-误伤量。
其中,误伤量可以通过误伤检测来计算。在这一讲最后“反爬虫误伤监测方法”会展开说明,而
线上爬虫总数需要通过爬虫占比来预估。
爬虫占比=爬虫量/总访问量
事实上,这个比例是持续变更的,因此不是一个固定值。所以,在工作交流中,我们也可以用“爬虫量”来代替“爬虫占比”。这里,我也会给你提供两个计算爬虫量的方法。
第一个方法,利用的是转化率不变的原则。
我们都知道,转化率=用户下单量/总UV。而转化率不变,其实是由于商品转化率取决于商品品质,用户画像等恒定不变的特征。那么,在这些恒定特征不变的情况下,我们可以认定,转化率在单日内不发生改变。
因此,我们可以得出一个推论:订单=访问量*转化率。因此,访问量=订单/转化率。如果转化率不变,那么订单曲线经过一个合适的乘法加权,订单曲线应该与流量曲线重合。如果两者不重合,那么差值就是爬虫量。
第二个方法,是从我们做爬虫的时候会“周期性的用JOB去抓取数据”这件事中提炼出来的方法。你会发现,这样周期性的抓取,会导致流量上存在周期性的爬虫流量。
用一句话来概括爬虫流量周期理论的话,那就是,如果订单曲线加权后与流量曲线做差,得到的曲线依然有周期性的差值,那么这个差值就是周期性的爬虫。可以直接刨除。
上述讲到的两个理论,虽然不能精准算出爬虫的占比,但是经过一些预估以及计算,当加权订单曲线可以与流量曲线重合时,就可以认为爬虫已经几乎被排除光了。那么,排除掉的那些流量,就是预估的当天爬虫量。
最后,我也给你提供一个取巧的方案:反爬虫的效果,取决于排除掉爬虫后的流量曲线,与加权订单的重合度。重合度越高,效果越好。这样,我们也可以不计算爬虫量,直接评估反爬虫效果。
在信息收集、占比预估的部分准备结束之后,我们就可以准备测试了。反爬虫策略直接上线风险极高,同时,我们还要联动测试团队,不能给他们拖后腿的理由。
我们都知道,反爬虫的代码有两部分,一部分是策略代码,一部分是框架代码。策略代码千变万化,难以穷尽,线上场景又十分复杂,因此,不适合线下测试。而框架代码不同,它本身是不变的,因此可以在线下进行测试,完善后再上线,降低上线风险。
所以,反爬虫线下测试,其实就是在上线前,使用测试环境,对反爬虫不变的框架代码,例如engine、规则引擎等等,进行详尽的测试,保证研发质量,降低上线风险。
那么,需要线上测试的策略代码呢?碰到测试环境无法模拟详尽的情况,是不是需要进行线上测试?但是,线上测试本身又存在风险,因此我们需要寻找安全的线上测试方法。
通常,反爬虫的策略提出时,他的安全性是存疑的。在线上运行一段时间后,如果还没出问题,那么可以认为对用户无伤害。但是如果存在问题,发现的时候,伤害已经造成,不能挽回。因此,我们可以借鉴青霉素皮试的方案,开启小流量尝试对用户进行伤害,这样可以在伤害最小的时候得出策略安全与否的结论。
然而,小流量的伤害依然可能是不可控的。我们可以再借鉴下疫苗的思路,进行假装拦截,看是否有问题。如果没问题,就让策略上线,成为“抗体”。
具体做法有四个步骤。首先,针对价格请求,除了线上策略外,我们可以额外增加测试策略A。接着,测试策略A本身如果鉴定请求为爬虫,不进行拦截,写入Cookie证明这是爬虫。但是注意要与线上的Cookie错开,避免无法拆分。再之后,我们可以在误伤检测看板观察误伤情况。由于这是测试策略,可以长时间观察,证明是否有害。最后,观察结束后可以将策略标记为“无害”,并下线测试策略。后续随时可以真正上线。
从刚才的四步中,你应该也可以明白了,反爬线上策略测试,指的是对线上流量进行模拟拦截,通过长时间观察,验证策略安全性的一种测试方法。这样,我们也就算找到了安全的线上测试方法。
最后,万一反爬虫真的出事了,我们也可以选择熔断。这个熔断的测试,其实就是:针对反爬虫的框架代码进行彻底关闭以及自动关闭功能的测试。我们的目标,永远是保护生产环境。
我们永远要记得,熔断并不是什么丢人的事情。反爬虫是一个低ROI的非关键需求,又容易出事。熔断,其实是属于牺牲自己,保护生产。
不过这里要注意的是,熔断本身也可能会引发新的故障,那就会导致额外的追责,不利于进一步发展反爬虫团队。新故障的解决方案,我们会在《14讲|低耦合》中详细讲解。
完成了信息收集、定量分析以及测试之后,我们就可以准备立项了。这里,我们通常会针对反爬虫低收益、高风险的特殊情况逐一分析。
反爬虫的需求分析,有极强的技术倾向,普通产品经常力不从心,甚至可能会拖后腿。因此,我更推荐由技术转行的反爬虫产品经理,而不是直接招聘。
反爬虫的需求分析,包括一次性需求分析以及持续性需求分析。一次性需求分析,通常定制化程度较高,可能产品突发奇想要做点什么,就成了反爬组的任务之一了。而持续性需求分析,包括爬虫进化追踪、数据变更、埋点检测、竞对监测等等,属于基础的监测。
至于收益分析,算下ROI就可以了。但是要注意,反爬虫是低收益项目,因此收益分析很关键。所以,如果真的需要分析收益,我们可以从信息保护,商业优势,竞对压制以及竞对爬虫资源消耗等方面切入。这些别人眼里的偏门,才是我们的价值所在。
立项的问题解决之后,我们就要考虑风险控制了。如果说反爬虫的收益分析主要用于项目组能生存下来,那么反爬虫的风险控制主要就是让自己能够不死。
反爬虫的风险点通常在于伤害用户体验、降低系统稳定性以及商誉PR风险等等。
针对伤害用户体验以及降低系统稳定性两点,我们都可以认为是系统问题。这里,我们通常有五种解决方法。
首先,我们可以增加小流量测试时间,因为小流量意味着小的伤害,可以用较长的时间,逐渐在不损伤用户的前提下发现问题,避免造成大的事故。同时,我们还可以使用静默测试,也就是只检测不拦截,类似战争演习,不真正造成损伤但是达到练兵的效果。第三点,我们也可以针对VIP用户,增加白名单机制。毕竟误伤了谁都不能误伤我们的VIP用户。那么针对短期、重要用户,我们也可以增加快速洗白逻辑,这也是我们的第四个方法。最后,我们甚至可以再增加快速熔断机制以及快速关闭机制,选择暂时放弃反爬。
至于商誉PR的风险,我们要么甩锅给技术、要么甩锅给竞对。当然了,推来推去也不是件什么得意的事,最关键的还是要增加全面日志,避免发生问题难以重现。
最后,如果真出了大问题,那应该就是大量误伤了用户,也就是将线上用户错误地识别成了爬虫。那么,怎么才能发现出了误伤的问题呢?我们通常选择在用户访问流的上游进行反爬测试,并针对爬虫进行标记,然后在下游进行标记检测的方法来检测误伤。理论上说,因为标记的都是爬虫,因此下游不可能读取到标记,一旦读取到,就是反爬虫误伤。
而出现了误伤之后,我们也可以增加静默测试时间来补救。在静默测试规则转为正式规则的时候,也一定要进行长时间的观察,同时要设置快速回退机制,保证在发布有问题的时候,能够退回到没发之前的状态。
现在,我们已经走完了整个反爬流程。我在这里也给你准备了一张反爬虫流程图。在你不知道要采取什么样的措施或动作的时候,希望它可以给你提示。
在开始反爬之前,我们做的就是明确反爬的目的,注意,我们不是一味地拦截,我们也没有机器人洁癖。反爬虫要做的核心,是找到那些ROI不高的账号。
所以在前期,我们需要收集不少的信息作为后续动作的参考。同时,我们也需要去评估整个反爬虫的效果。效果的重点不在于数量,而在于商业上的胜利。在反爬虫系统正式上线前,我们也需要通过一系列的线上、线下测试。最后,基于反爬的特殊性,我们更需要明确这项工作的收益点,同时将风险降到最低。
作为理论与实践案例篇的最后一讲,今天的思考题还是有些不同的。
不知道你还能不能想起来在这一讲开始的时候我给你描述的情境。想象一下,如果这上面的所有理论梳理,都是你在给领导讲述下个月的可行动作呢?现在,你的领导应该已经忍不住哈哈大笑了吧——好像自己下个双月的所有规划已经写好,可以划水了。
这个时候,你们所在的小龙虾摊位的老板也走过来,又上了一盘小龙虾,忍不住问道,“二位是做互联网的吧?今天是不是谈了什么非常开心的事情?”
也许,你会不由得大惊,问道:“老板你怎么知道的,你偷听了我们的全部谈话么?这个规划我们还没写,你可不能透露出去啊,不然没准明天就成别人的规划了,”
老板笑了笑:“放心吧,没怎么听,只是感觉你们刚开始愁眉苦脸,不说人话,我就感觉你们应该是做互联网的。然后谈着谈着慢慢开始正常讲话了,谈开心了,就忍不住暴露本性说起了人话,我在这修罗城也卖了三十多年的小龙虾了,不说人话的互联网人都会堕落到这里来,只要说上几句人话,就能逃脱苦海,回归正常生活,然而我这生意是越做越红火,流量也是越来越大,我在小龙虾里也对配料进行了AB测试,看起来你们吃的这个版本的配方,是效果最好的啊!你们抬头看看,今天的月色美不美。”
你忍不住抬起头来,看了看天上的圆月,忍不住一阵头晕,忽然感觉空间扭曲,时间混乱,一眨眼,自己居然拿着手机在听极客时间,耳边又传出了熟悉的声音:
“你好,我是DS Hunter,刚刚就是理论课的全部内容,真的十分枯燥,希望你没有听睡着。下面是愉快的思考题时间:”
期待你的不正经回复,我会在评论区与你们愉快地进行更不正经的互动。
© 2019 - 2023 Liangliang Lee. Powered by gin and hexo-theme-book.