Go语言网络爬虫中的基本数据结构

为了承载和封装数据，需要先声明一些基本的数据结构。网络爬虫框架中的各个模块都会用到这些数据结构，所以可以说它们是这一程序的基础。

在分析网络爬虫框架的需求时，提到过这样几类数据——请求、响应、条目，下面我们逐个讲解它们的声明和设计理念。

请求用来承载向某一个网络地址发起的 HTTP 请求，它由调度器或分析器生成并传递给下载器，下载器会根据它从远程服务器下载相应的内容。因此，它有一个 net/http.Request 类型的字段。

不过，为了减少不必要的零值生成（http.Request 是一个结构体类型，它的零值不是 nil）和实例复制，我们把 *http.Request 作为该字段的类型。下面是 base.Request 类型的声明的第一个版本：

//数据请求的类型
type Request struct {
    // HTTP请求
    httpReq *http.Request
}

我把基本数据结构的声明都放到了示例项目下的代码包 gopcp.v2/chapter6/webcra-wler/module 中。因此，其他代码包中的代码在访问这些类型时一般会用到限定符 module。示例项目大家可以从我的网盘中下载（链接：https://pan.baidu.com/s/1yzWHnK1t2jLDIcTPFMLPCA 提取码：slm5 或 本地下载）。

从已经提到的相关需求来看，这样的声明已经足够了。不过，我也说过网络爬虫能够在爬取过程结束之后自动停止。那么，网络爬虫在对一个网站上的内容爬取到什么程度才结束呢？量化内容爬取程度的一个比较常用的方法，是计算每个下载的网络内容的深度。

网络爬虫可以根据最大深度的预设值忽略掉对“更深”的网络内容的下载。当所有在该最大深度范围内的网络内容都下载完成时，就意味着爬取过程即将结束。待这些内容分析和处理完成后，就能够判定网络爬虫对爬取过程的执行是否真正结束了。因此， 为了记录网络内容的深度，我们还应该在 Request 类型的声明中加入一个字段，它的第二个版本如下：

//数据请求的类型
type Request struct {
    // HTTP请求
    httpReq *http.Request
    //请求的深度
    depth uint32
}

//用于创建一个新的请求实例
func NewRequest(httpReq *http.Request, depth uint32) *Request {
    return &Request{httpReq: httpReq, depth: depth}
}

//用于获取 HTTP 请求
func (req *Request) HTTPReq() *http.Request {
    return req.httpReq
}

//用于获取请求的深度
func (req *Request) Depth() uint32 {
    return req.depth
}

我希望这个类型的值是不可变的。也就是说，在该类型的一个值创建和初始化之后， 当前代码包之外的任何代码都不能更改它的任何字段值。对于这样的需求，一般会通过以下 3 个步骤来实现。

1) 把该类型的所有字段的访问权限都设置为包级私有。也就是说，要保证这些字段 的名称首字母均为小写。

2) 编写一个创建和初始化该类型值的函数。由于该类型的所有字段均不能被当前代码包之外的代码直接访问，所以它们自然也就无法为这样的字段赋值。这也是需要编写这样一个函数的原因。这类函数的名称一般都以“New”为前缀，它们会接受一些参数值，然后以此为基础初始化一个目标类型的值并将其作为函数结果返回。

3) 编写必要的用来获取字段值的方法。这一步骤并不是必需的。不编写这样的方法的原因可能是想要完全隐藏字段值，也可能是字段的类型导致不宜公开其值。比如，如果字段是引用类型的，那么只要它的值可以被外部获取，就等于让外部有了修改权限。

注意，NewRequest 函数的结果类型是 *Request，而不是 Requesto 这样做的主要原因是要为 Request 类型编写指针方法而非值方法，并以此让 *Request 成为某个接口类型的实现类型。更深层次的原因是，值在作为参数传递给函数或者作为结果由函数返回时会被复制一次。指针值往往更能减小复制的开销。

这里再说明一下 Request 类型的 depth字段。理论上，uint32 类型已经可以使 depth 字段的值足够大了。由于深度值不可能是负数，所以也不需要为此牺牲正整数的部分取值范围。传递给调度器的首次请求的深度值是 0，这也是首次请求的一个标识。

那么，后续请求的深度值应该怎样计算和传递呢？假设下载器发出了首次请求“A”并成功接收到了响应，经过分析器的分析，其中找到了两个新的网络地址并生成了新的请求“B”和“C”，那么这两个新请求的深度值就为 1。

如果在接收并分析了请求“B”的响应之后又生成了一个新请求“D”，那么后者的深度值就是 2，以此类推。我们可以把首次请求看作请求“B”和请求“C”的父请求，反过来讲，可以把请求“B”和请求“C”视作首次请求的子请求。

因此，就有了这样一条规则：一个请求的深度值等于对它的父请求的深度值递增一次后的结果。

理解了刚刚对请求深度值计算方法的描述之后，你可能会发现：只有对某个请求的响应内容进行分析之后，才可能需要生成新的请求。并且，调度器并不会直接把请求作为参数传递给分析器。这样不符合我们先前对数据流转方式的设计，同时也会使这两个处理模块之间的交互变得混乱。

显然，响应也携带深度值。一方面，这可以算作标示响应深度的一种方式。另一方面，也是更重要的一方面，它可以作为新请求的深度值的计算依据。因此，Response 类型的声明如下：

//数据响应的类型
type Response struct {
    // HTTP响应
    httpResp *http.Response
    //响应的深度
    depth uint32
}
//用于创建一个新的响应实例
func NewResponse(httpResp *http.Response, depth uint32) *Response {
    return &Response{httpResp: httpResp, depth: depth}
}
//用于获取HTTP响应
func (resp *Response) HTTPResp() *http.Response {
    return resp.httpResp
}

//用于获取响应深度
func (resp *Response) Depth() uint32 {
    return resp.depth
}

这个类型的声明不再做解释，其各部分的含义与 Request 类型类似。

除了请求和响应这两个有着对应关系的数据结构之外，还需要定义条目的结构。条目的实例需要存储的内容比请求和响应复杂得多。因为对响应的内容进行筛选并生成出条目的规则也是由网络爬虫框架的使用者自己制定的。

因此，条目的结构足够灵活，其实例可以容纳所有可能从响应内容中筛选出的数据。基于此，我这样定义条目的类型声明：

我们把 Item 类型声明为字典类型 map[string]interface{} 的别名类型，这样就可以最大限度地存储多样的数据了。由于条目处理器也是由网络爬虫框架的使用者提供，所以这里并不用考虑字典中的各个元素值是否可以被条目处理器正确理解的问题。

好了，我们需要的 3 个基本数据类型都在这里了。为了能够用一个类型从整体上标识这 3 个基本数据类型，我们又声明了 Data 接口类型：

这个接口类型只有一个名为 Valid 的方法，可以通过调用该方法来判断数据的有效性。显然，Data接口类型的作用更多的是作为数据类型的一个标签，而不是定义某种类型的行为。为了让表示请求、响应或条目的类型都实现 Data 接口，又在当前的源码文件中添加了这样几个方法：

//用于判断请求是否有效
func (req *Request) Valid() bool {
    return req.httpReq != nil && req.httpReq.URL != nil
}

//用于判断响应是否有效
func (resp *Response) Valid() bool {
    return resp.httpResp != nil && resp.httpResp.Body != nil
}

//用于判断条目是否有效
func (item Item) Valid() bool {
    return item != nil
}

这样一来，这 3 个类型因 Data 接口类型而被归为一类。在后面，你会了解到这样做还有另外的功效。

至此，实现网络爬虫框架需要用到的基本数据类型均已编写完成。不过，这里我们还需要一个额外的类型，这个类型是作为 error 接口类型的实现类型而存在的。它的主要作用是封装爬取过程中出现的错误，并以统一的方式生成字符串形式的描述。

我们知道, 只要某个类型的方法集合中包含了下面这个方法，就等于实现了 error 接口类型：

为此，首先声明了一个名为 CrawlerError 的接口类型：

我们把它放在了 gopcp.v2/chapter6/webcrawler/errors 代码包中，其中 Type 方法的结果类型 ErrorType 只是一个 string 类型的别名类型而已。另外，由于 CrawlerError 类型的声明中也包含了 Error 方法，所以只要某个类型实现了它，就等于实现了 error 接口类型。

先编写这样一个接口类型而不是直接编写出 error 接口类型的实现类型的原因有两个。第一，我们在编程过程中应该遵循面向接口编程的原则，这个原则我已经提过多次了。第二是为了扩展 error 接口类型。网络爬虫框架拥有多个处理模块，错误类型值可以表明该错误是哪一个处理模块产生的，这也是 Type 方法起到的作用。

下面就让我们来实现这个接口类型。遵照本书中对实现类型的命名风格，我们声明了结构体类型 myCrawlerError：

字段 errMsg 的值由初始化 myCrawlerError 类型值的一方给出，这与传递给 errors.New 函数的参数值的含义类似。作为附加信息，errType 字段的值就是该类型的 Type 方法的结果值，它代表了错误类型。为了便于使用者为该字段赋值，还声明了一些常量：

可以看到，这 4 个常量的类型都是 ErrorType，它们分别与网络爬虫框架中的主要模块相对应。当某个模块在运行过程中出现了错误，程序就会使用对应的 ErrorType 类型的常量来初始化一个 CrawlerError 类型的错误值。具体的初始化方法就是使用 NewCrawler-Error 函数，其声明如下：

从该函数的函数体可以看出，*myCrawlerError 类型是 CrawlerError 类型的一个实现类型。*myCrawlerError 型的方法集合中包含 CrawlerError 口类型中的 Type 方法和 Error 方法：

func (ce *myCrawlerError) Type() ErrorType {
    return ce.errType
}

func (ce *myCrawlerError) Error() string {
    if ce.fullErrMsg == "" {
        ce.genFullErrMsg()
    }
    return ce.fullErrMsg
}

你可能已经发现，Error 方法中用到了 myCrawlerError 型的 fullErrMsg 字段。并且，它还调用了一个名为 genFullErrMsg 的方法，该方法的实现如下：

//用于生成错误提示信息，并给相应的字段赋值
func (ce *myCrawlerError) genFullErrMsg() {
    var buffer bytes.Buffer
    buffer.Writestring("crawler error:")
    if ce.errType != "" {
        buffer.WriteString(string(ce.errType))
        buffer.WriteString(":")
    }
    buffer.WriteString(ce. errMsg)
    ce.fullErrMsg = fmt.Sprintf("%s", buffer.String())
    return
}

genFullErrMsg 方法同样是 myCrawlerError 类型的指针方法，它的功能是生成 Error 方法需要返回的结果值。可以看到，这里没有直接用 errMsg 字段的值，而是以它为基础生成了一条更完整的错误提示信息。在这条信息中，明确显示岀它是一个网络爬虫的错误，也给出了错误的类型和详情。

注意，这条错误提示信息缓存在 fullErrMsg 字段中。回顾该类型的 Error 方法的实现，只有当 fullErrMsg 字段的值为 "" 时，才会调用 genFullErrMsg 方法，否则会直接把 fullErrMsg 字段的值作为 Error 方法的结果值返回。

这也是为了避免频繁地拼接字符串给程序性能带来的负面影响。在 genFullErrMsg 方法的实现中使用了 bytes.Buffer 类型值作为拼接错误信息的手段。

虽然这样做确实可以大大减小这一负面影响，但是由于 myCrawlerError 类型的值是不可变的，所以缓存错误提示信息还是很有必要的。其根本原因是，对这样的不可变值的缓存永远不会失效。

前面展示的这些类型对于承载数据（不论是正常数据还是错误信息）来说已经足够了，它们是网络爬虫框架中最基本的元素。