Docker swarm部署splash服务集群+HAProxy负载均衡

docker stack deploy建立多服务集群并使用HAProxy搭建负载均衡

github中有一个非常好的单机多开splash Docker container的方案,但是,它仅仅适用于单机,如果是集群,它就无法应付了。这篇文章主要是解决集群部署splash的方案,Google半天也没有现成的方案,自己琢磨了下搞定了。

https://github.com/TeamHG-Memex/aquarium

适用平台: windows 10, centos 7.6

技术方案:利用yaml搭建Docker Swarm集群并部署多个服务(Visualizer, splash 3.5.0, HAproxy)

为什么用yml呢?看下下面docker service create,一次只能搭建一个服务,想搭建多个就不太方便,也不容易定制一些参数

集群建设

(boss) [chen@VM_0_3_centos aquarium]$ docker service create -p 8050:8050 –replicas 6 –name splash scrapinghub/splash /bin/bash
j3qtsdci0qum515nzoxpxu7u4
overall progress: 6 out of 6 tasks
1/6: running [==================================================>]
2/6: running [==================================================>]
3/6: running [==================================================>]
4/6: running [==================================================>]
5/6: running [==================================================>]
6/6: running [==================================================>]
verify: Service converged

Prerequisite: docker-ce (Linux平台需要单独安装,只安装docker是不够的) 或者Docker for windows, windows平台是集成化。

version: “3”

services:
visualizer:
image: dockersamples/visualizer
volumes:
– “/var/run/docker.sock:/var/run/docker.sock”
ports:
– 8080:8080
deploy:
placement:
constraints: [node.role == manager]
# labels:
# – com.df.notify=true
# – com.df.serviceDomain=visualizer.youclk.com
# – com.df.port=8080
# – com.df.usersSecret=admin

yml文件如下:

splash:
    image: scrapinghub/splash
    ports:
        - 8050:8050

    deploy:
        mode: replicated
        replicas: 2
        labels: [APP=SPLASH]
        # service resource management
        resources:
            # Hard limit - Docker does not allow to allocate more
            limits:
                cpus: '0.25'
                memory: 2048M
            # Soft limit - Docker makes best effort to return to it
            reservations:
                cpus: '0.25'
                memory: 2560M
        # service restart policy
        restart_policy:
            condition: any
            delay: 5s
            max_attempts: 3
            window: 120s

        # placement constraint - in this case on 'worker' nodes only
        placement:
            constraints: [node.role == worker]

(boss) [chen@VM_0_3_centos aquarium]$ docker stack deploy -c docker-compose.yml splash
Updating service splash_visualizer (id: lcfw3l45xkvewmly5yz7ukywh)
Updating service splash_splash (id: v1s5gbl9nfzmmp1hct6c8okce)

如果之前运行过上述命令,那么重新运行时会更新服务,方便扩展。因为replicas是2,每个服务器只创建了一个splash container。

然后我把replica改成4,Visualizer监控界面就看到了4个container:

来看一下其中一个服务器,能看到两个不同时间创建的container:

(boss) [chen@VM_0_2_centos ~]$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0ae3f202164d scrapinghub/splash:latest “python3 /app/bin/sp…” 3 minutes ago Up 3 minutes 8050/tcp splash_splash.1.kpj3rv7piojx4yq3h5w3vamtv
9d353fe1bd6a scrapinghub/splash:latest “python3 /app/bin/sp…” 27 minutes ago Up 26 minutes 8050/tcp splash_splash.3.bl3amsvyticoje9vv3yethp4c

那么,为什么说它是高可用呢?我们重启或者停下VM_0_2_centos下的一个container,我们看到集群重新建了一个container:

(boss) [chen@VM_0_2_centos ~]$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0ae3f202164d scrapinghub/splash:latest “python3 /app/bin/sp…” 3 minutes ago Up 3 minutes 8050/tcp splash_splash.1.kpj3rv7piojx4yq3h5w3vamtv
9d353fe1bd6a scrapinghub/splash:latest “python3 /app/bin/sp…” 27 minutes ago Up 26 minutes 8050/tcp splash_splash.3.bl3amsvyticoje9vv3yethp4c
(boss) [chen@VM_0_2_centos ~]$ docker stop 0ae3f202164d
0ae3f202164d
(boss) [chen@VM_0_2_centos ~]$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d9253824289f scrapinghub/splash:latest “python3 /app/bin/sp…” 39 seconds ago Up 33 seconds 8050/tcp splash_splash.1.fo051grhynfybzbh407a1hith
9d353fe1bd6a scrapinghub/splash:latest “python3 /app/bin/sp…” 30 minutes ago Up 29 minutes 8050/tcp splash_splash.3.bl3amsvyticoje9vv3yethp4c

这个集群会努力保持集群中始终有4个container,如果一个死掉或者重启了会立即重建一个container,如果一个服务器宕机了,那么会在其他服务器重建4个container。当然,前提是你的服务器没有全部GG了

文中没有细说集群建设,网络中到处是这种帖子,简单说下:

创建管理节点manager node:

docker swarm init –advertise-addr=Manager IP

运行这个命令后会提示一个token,用这个token在worker node上运行下面命令即可加入集群,非常方便,不需要考虑网络问题:

docker swarm join –token SWMTKN-1-0zhhp71dfw77axxiuoixrechl8kcd9tapi9tbqskgtvt9yxxxxxxxxxxxxxxxxxxxxxxx –advertise-addr=WORKER IP:8050

HAproxy负载均衡

虽然swarm据说也有负载均衡,但是我测试了下,它的负载均衡仅仅限于一个节点上,外面还要套一层负载均衡才能对外服务,这个可以参考Youtube上的微软工程师的视频: https://www.youtube.com/watch?v=ZfMV5JmkWCY&t=170s

视频一共三个,第三个提到了负载均衡提供对外服务。这里我用一个性能很弱的腾讯云服务器做的负载均衡,也是docker集群的管理节点。

HAProxy监控界面
# HAProxy 1.7 config for Splash. It assumes Splash instances are executed
# on the same machine and connected to HAProxy using Docker links.
global
    # raise it if necessary
    maxconn 512
    # required for stats page
    stats socket /tmp/haproxy

userlist users
    user USER insecure-password PASSWD

defaults
    log global
    mode http

    # remove requests from a queue when clients disconnect;
    # see https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4.2-option%20abortonclose
    option abortonclose

    # gzip can save quite a lot of traffic with json, html or base64 data
    # compression algo gzip
    compression type text/html text/plain application/json

    # increase these values if you want to
    # allow longer request queues in HAProxy
    timeout connect 3600s
    timeout client 3600s
    timeout server 3600s


# visit 0.0.0.0:8036 to see HAProxy stats page
listen stats
    bind *:8036
    mode http
    stats enable
    stats hide-version
    stats show-legends
    stats show-desc Splash Cluster
    stats uri /
    stats refresh 10s
    stats realm Haproxy\ Statistics
    stats auth    admin:adminpass


# Splash Cluster configuration
# 代理服务器监听全局的8050端口
frontend http-in
    bind *:8050
    # 如果你需要开启Splash的访问认证
    # 则注释default_backend splash-cluster
    # 并放开其余default_backend splash-cluster 之上的其余注释
    # 账号密码为user  userpass
    acl auth_ok http_auth(users)
    http-request auth realm Splash if !auth_ok
    http-request allow if auth_ok
    http-request deny

    acl staticfiles path_beg /_harviewer/
    acl misc path / /info /_debug /debug

    use_backend splash-cluster if auth_ok !staticfiles !misc
    use_backend splash-misc if auth_ok staticfiles
    use_backend splash-misc if auth_ok misc
    default_backend splash-cluster


backend splash-cluster
    option httpchk GET /
    balance leastconn

    # try another instance when connection is dropped
    retries 2
    option redispatch
    # 将下面IP地址替换为你自己的Splash服务IP和端口
    # 按照以下格式一次增加其余的Splash服务器
    server splash-0 SPLASH0_IP:8050 check maxconn 50 inter 2s fall 10 observe layer4
    server splash-1 SPLASH1_IP:8050 check maxconn 50 inter 2s fall 10 observe layer4

backend splash-misc
    balance roundrobin
    # 将下面IP地址替换为你自己的Splash服务IP和端口
    # 按照以下格式一次增加其余的Splash服务器
    server splash-0 SPLASH0_IP:8050 check fall 15
    server splash-1 SPLASH1_IP:8050 check fall 15

重磅: scrapy crawl SPIDER -a http_user=’USER’ -a http_pass=’PASSWD’

splash加密访问之后,如何在scrapy项目中利用是个问题,这个命令行解决了一大难题。网络上多数帖子都是抄袭的,这种关键问题却是没几个人提到。如果像我一样你想用多进程,一个服务器开多个scrapy进程,那么下面的脚本能解决你的问题:

from scrapy.crawler import CrawlerProcess
from scrapy.utils.project import get_project_settings
from multiprocessing import Pool
import os, time, random, multiprocessing

def long_time_task(name):
    # 如下代码中加入异常捕捉后可以正常返回结果,防止主进程一直被阻塞
    pid=os.getpid()
    try:
        print('pid:%d'%pid)
        print('Run task %s (%s)...' % (name, os.getpid()))
        start = time.time()
        process = CrawlerProcess(get_project_settings())
        process.crawl('lagouspd', domain='lagou.com', http_user='USER', http_pass='PASSWD')
        process.start(stop_after_crawl = False) # the script will block here until the crawling is finished       
        end = time.time()
        print('Task %s runs %0.2f seconds.' % (name, (end - start)))       
        time.sleep(2)
    except KeyboardInterrupt:
        print('进程%d被中断...'%pid)



if __name__=='__main__':
    print('Parent process %s.' % os.getpid())
    try:
        p = Pool(multiprocessing.cpu_count()*4)
        for i in range(multiprocessing.cpu_count()*4):
            p.apply_async(long_time_task, args=(i,))
            time.sleep(random.random() * 3)
        print('Waiting for all subprocesses done...')
        p.close()
        p.join()
        print('All subprocesses done.')
    except KeyboardInterrupt:
        print('catch keyboardinterupterror')
        pid=os.getpid()
        os.popen('taskkill.exe /f /pid:%d'%pid) #在unix下无需此命令,但在windows下需要此命令强制退出当前进程
    except Exception as e:
        print(e)
    else:
        print('quit normally')        

脚本中的用户名密码就是上面的USER, PASSWD,不然splash没法使用。该脚本还解决了multiprocessing多进程用进程池时没法CTRL C暂停爬虫的问题

scrapy-redis搭配splash全站爬虫

上一次爬取BOSS直聘,我高调地在领英上发了几个帖子,结果招来了BOSS直聘一个高管的访问,还好我只爬了100多万职位数据,每天最多爬取8-10万,估计没有给对方服务器带来太大压力,不然我可能因为一时兴起惹了麻烦。

爬取BOSS直聘时我是自建的框架,最关键的突破当然是跨越了selenium阻塞影响并发这道坎儿。实际上,很多情况下设置下Desired_Capability中的page_load policy为’None’,selenium几乎就成了非阻塞了。当然,这个小秘密初学者一般不知道,大都会抱怨selenium的慢。我测试过,采用这种策略,不到1秒就能返回页面数据,印象中应该是几十到几百毫秒吧。

即便如此,我还是没能完美解决selenium超时这个问题,毕竟是模拟浏览器,它在超时的时候往往会停止响应,阻塞下面的流程,怎么设置timeout参数都没用。后来我发现,多进程会稳定很多,多线程timeout带来的阻塞问题在多进程并不是太大的问题,一是线程独立,挂掉一个互不影响,二是如果真的阻塞了可以根据pid来杀死进程重启。当然,我没有用scrapy搭配selenium,以后有机会可以试试。

BOSS直聘的反爬还是有点水平的,主要是它很容易弹出验证码。我用过多贝云和阿布云的隧道代理,两家质量差不多,都不错,只是动态版的IP响应速度会慢一些。问题是每个IP用在BOSS直聘效果不一样,有的估计之前被人用过所以第一次就被BOSS黑了,好点的话一般短时间内爬取好像20页问题不大。当然我还用ADSL自建过代理池,效果一般,主要是ADSL主机只有两个,池子小了容易造成程序等待IP代理。

这次爬取拉勾网,我才用了新的框架,scrapy-redis-splash,研究了几天就上手了。说实话,写这种程序和平时处理分析地震数据思维是一样的,只是工具不同而已。找出问题-问题分解-解决问题,都是这么一个思路。总结下这个框架吧。

  1. scrapy: 成熟框架,容易上手,但是因为是框架,需要多读文档多读源码才行,不是自建的轮子用起来不是很顺手,毕竟不能控制主循环。
  2. redis:因为之前做代理池就用过,这次用起来也很顺手。redis去重和调度并不像文档说的那么简单,比如爬虫重启时会有个问题,硬重启需要删除之前的requests,问题是之前的url虽然爬取过进了dupefilter,但是并没有成功爬取Item,重启后这些就会被过滤了。这个应该不难解决,我有时间看看源码。
  3. splash。这个才是重头戏,splash有个问题就是不释放内存,即使我的笔记本有32G内存也会很快被耗尽,虽然代码中我做了内存监控重启docker,也不是很完美。这个还是小问题,代码中可以监控或者启动docker时限制内存使用即可,大问题是504 gateway timeout,官方文档中和网络上说的设置一个很大的timeout实际上不好使,504照样还是很多,而且我发现只要是504就会阻塞,设置过大了程序有时就卡住了,太小了504就更多。504告诉我们的实际上就是splash没能及时渲染出网页,这个的终极解决方案是HAproxy做一个load balancer,用多个docker instance(2G内存一个都可以),甚至自己的笔记本都能并发多个实例。这里我用了Acquarium, github上有,Acquarium唯一的坑就是在Docker for windows下你可能无法登录8036那个监控页面,这里涉及到了Docker和宿主机的网络问题,比较复杂,启用ubuntu WSL2 backend就好了,然后就能访问127.0.0.1:8036来看负载均衡的状态监控了。
  4. 再说说拉勾网吧,难度很低,几乎没有反爬,甚至不限制IP访问频率!当然,你不能调用网络上盛传的那个端口来获取json,况且那个接口只能获取列表页,不能获取详情页。
  5. IP变化少的情况下要考虑网站的CDN,如果不用多地区的不同IP,爬虫速度很难上去,毕竟CDN节点会有限速啊!

熟悉了框架,就能用它来爬取高难度的网站了。目前计划爬取的几个目标:

  1. 京东。全站爬取估计很费劲,京东自称有500多万sku,京东虽然是树形结构,但是这么多商品肯定要细分类才能爬到更多数据,URL去重无法避免,不同组合之间的元素会有交集啊。因为是电商,还需要它的评论数据,很多热门商品都是几万几十万评论,爬起来也很费时。当然,之前我做过京东商品抢购的脚本,虽然没能抢到茅台,但是能用到这个爬虫中。
  2. 拼多多。电商中的黑马,虽然我从来不用。
  3. 唯品会,媳妇儿的最爱,怎能不光顾下?
  4. 携程,去哪儿,爱彼迎。爱旅游的我自然对他们感兴趣
  5. 出行必备滴滴。这个得看看它的APP,看看有没有接口,估计难度不小。
  6. 12306,爬虫们的最爱。
  7. 小红书,潮人们的必备APP
  8. 抖音,快手,虽然我从来不用,也没有装。刷视频比追剧还要浪费时间
  9. 学习强国,这个PC端我已经写好了,APP端因为目前要用HyperV(docker),不太方便使用安卓模拟器。还需要一个题库API,有时间我做下

不说了,这些够我忙活大半年了。边爬边分析吧。

拉勾网爬虫截屏,单机4进程*10线程, 6个splash instance,200KB/s – 1MB/s,平均2.5个职位/秒