项目航海

项目航海–A2D产品的前世今生

撰写时间2018年8月10日 星期五 上午10:59至2018年8月16日 星期四 下午16:40

  本文不同于作者之前写过的任何博文，是作者纯粹的研发经历和思路手书，以前的技术博文或多或少会摘取网络上的产品思路和技术想法，而此文更像是一个从无到有的产品经历，而非产品介绍或者技术讲解。作者本身是一个从业两年出头三年不到，脱离技术小白不久却离大牛之路遥遥无期的技术人员，有过六七个大型项目的研发经历，带过三四个完整的中小型项目，自认头脑不算聪慧却还灵活，受限于从业经历相对简单，时限较短，眼光还尚显稚嫩，故而纯手书的此文或多或少会存在一些技术问题和产品设计漏洞，希望阅读此文的读者可以谅解，如果有好的想法和提议，欢迎和作者进行交流，促进共同的进步，在此表达感谢！
                                   —-前言

  浏览本文，首要必须搞清楚几个核心问题，A2D是什么，爬虫技术应用于何处，工具本身的行为出发点在哪，产品的切入点为何？

  要解答这些问题，作者思前想后很久，还是得先从产品的来源和最初的需求说起。

  A2D这个命名来源于鄙公司2017年一个几近失败的项目，该项目采用仿制市面上流行的某python爬虫工具，进行了java重写和功能重塑，技术核心部分中对于验证登录是做了如下处理：
1.对于不需要登录的站点，无需填写cookie；
2.对于需要登录的系统，则是采用填写登录信息后从浏览器去直接复制cookie，然后填进工具避开登录。核心爬取功能则是通过用户填写正则表达式，从页面中截取出本次采集所需要的站点数据，然后进行数据持久化。

该产品存在三个巨大的设计问题：
1.如果采集的系统模块过于庞大繁杂，会出现内存溢出，系统卡死，用户体验性差；
2.非技术人员如果并未经过系统培训，不清楚如何从浏览器获取cookie并复制进工具，不知道如何判断正则以及编写正则，就无法获取到想要的数据，用户体验过于复杂难懂，学习成本高。
3.由于工具本身只获得数据，导致UI及其简单，从产品设计的角度看，拓展延伸性差，市场推广难度大。

  基于高层对于该产品的满意度低，研发中心对于A2D提出了新的产品研发要求，将需求进行了重新整理，并给出了以下目标：
1.项目针对主要目标为政务系统，需要绕行登录验证（所采集系统提供登录用户名密码）；
2.采集的数据为系统各个模块的表格头部信息（所采集系统提供各个模块的url）；
3.对于采集下来的表头信息进行预处理（转化为政务系统中的信息资源信息项）；
4.尝试进行自动化采集的设计（定时进行系统模块表头信息的获取，由于cookie存在过期的情况，采用cookie登录的爬虫系统无法尝试在无人使用的情况下采集数据）。

  由此，才有了这个产品接下去的一系列故事。

  在接到这个产品之初，作者以及作者的团队成员从来没有接触过爬虫这类概念，使得作者闹了盲人摸象的设计错误，一度按照传统政务系统的方式进行项目管理和产品设计，在业务架构和工具构成上犯了众多常识性错误，再加上当时需求的紧迫度很高以及一些现实状况（疲于应付上级的检查）的干扰，导致没有合理运用投石问路的方式进行前期项目风险评估，也没有全方位针对现在主流的工具进行分析，使得产品设计初期的业务架构非常的脆弱不稳定，简单无亮点。

  起初经过不到两天的紧张调研和讨论后，采用了最初的结构划分和业务流程：
当时的系统设计分为三个模块：

1.登录绕行模块；
2.页面爬取模块；
3.内容处理模块。

  当作者以及团队成员饱含信心开始进行功能细化，准备进行工具开发时，登时就被泼了一盆冷水，在登录绕行模块，就受到了阻碍，自以为合理的登录绕行并没有一个可行的方案，以下列举出当时作者和副手商量的几个尝试性方案：
1.在工具的站点配置功能，将目标系统的登录页内置进来，输入登录信息后请求登录，一旦成功则通过某种方式自动从浏览器去读取当前可用的cookie，保存后完成登录的绕行；
2.避免获取cookie的方式，爬取登录页的用户名密码验证码的字段名，在配置页面让用户输入用户名密码验证码，试图从请求后拼接username和password来进行后端模拟登录。

  第二个方案从一开始就被确认为几乎不可行，因为我们没法真正绕过附骨之蛆的验证码，就是这个讨厌的验证码让作者耗尽心思，对于爬虫来说，验证码就像是杀虫剂。而且，并非所有系统的登录采用的请求方式都是一样的，我们是无法去操作我们的目标系统，这就导致这个方案无疾而终了。

  那就尝试第一个方案吧，在当时的情况下做出了无奈之举，作者和副手认真研究了市面上的八抓鱼，发现它可以做到类似于这个方案的效果，这让当时的我们欣喜若狂，但是这个欢喜持续了不到两天就消失了，这个方式完美得避开了验证码，却套入了浏览器的大坑中，为了做安全控制，防止xss攻击，浏览器有内置的httponly属性，而我们无法从前端更改它，甚至读取不了此属性，借用其他第三方的浏览器插件强制更改后的成功更是让当时的我们接受不了，甚至于当时的作者打算产品中加上一个插件下载链接和使用手册（这当然是开玩笑的，并不可行），对此，作者得出的结论是八抓鱼与其说是一个爬虫工具，更像是一个套着工具外壳的自制简化版浏览器，站在上帝的视角处理打开的网页，执行想要的操作然后获取想要的数据，几乎很少存在限制（此处评论是来自于作者短浅的见解），而我们却无法像它一样去做一个自己的浏览器，让人徒呼奈何。之后我们又发现了一个问题，即使我们有了cookie中的jsessionid，也可能无法处理单用户登录的系统，当然这个并没有做深入尝试，只是提出了一个猜想，因为当时我们的测试遇到了一个和url相关的问题，并且这个问题让人印象深刻。

  问题是由于我们所测试系统是鄙公司开发的政务服务系统，我们开始模拟用户使用环境下系统的可行性，但是，当我们尝试第一个系统时，问题就出来了，当我们登录系统，人工选择其中一个模块想要获取它的url时，发现浏览器地址栏并未发生变化，我们明白这是系统本身的过滤器起到了作用，那么从f12直接去找前端的模块路径总可以吧，结果让人啼笑皆非，我们尝试在浏览器输入得到的模块完整url，结果却得不到iframe中的页面，这个结果让作者一头雾水，开发过程中我们往往会在浏览器输入get请求的方法测试自己的对外接口是否正确，为何会无结果，经过一系列艰苦卓绝（毫无头绪进行中，作者以及副手都是java后台程序员出身，前端技能相对薄弱）地排查，发现原来我们所测试系统的前端在页面渲染前，对字典数据进行了一次初始化加载，将其放在了iframe外，如果是整个系统是可以显示的，但是如果是只取iframe中的一部分，会导致下拉选择的控制器读取字典值失败，让前端程序死在了胚胎中。这个排查结果大大打击了当时的研发情绪，怀疑论一度弥漫开来。

  如果前端有各种各样奇奇怪怪的数据处理方式，而且各种框架进阶速度那么快，怎么保证我们的产品有足够的容错率。直至今日，这个问题仍然是我思考的一个重大方向，且没有啥突破性进展，只能自己安慰自己，任何技术都是存在时效性的。
  好在作者以及副手当时对于登录模拟方式，在交流中迸发了灵光一现，才使得项目进程出现了一丝转机。经过一下午的研讨以及尝试，我们提出了第三个方案，之后陆陆续续修正过，但是当时的大纲并未发生变化，方案如下：
3.同样需要绕开cookie，先爬取登录页，获取到用户名密码验证码的精准定位，得到输入的用户名密码验证码，然后采用PhantomJS模拟浏览器进行机器模拟人为登录操作。

  这里简单介绍下PhantomJS，PhantomJS是一个无界面的,可脚本编程的WebKit浏览器引擎。它原生支持多种web 标准：DOM 操作，CSS选择器，JSON，Canvas 以及SVGPhantomJS是一个无界面的,可脚本编程的WebKit浏览器引擎。它原生支持多种web 标准：DOM 操作，CSS选择器，JSON，Canvas 以及SVG。简单来说，PhantomJS就是一个可编程的无头浏览器.而无头浏览器就是一个完整的浏览器内核,包括了js解析引擎,渲染引擎,请求处理等,但是不包括显示和用