这是「进击的Coder」的第 520 篇技术分享
作者：崔庆才
最近大家应该陆陆续续收到《Python3网络爬虫开发实战（第二版）》的书了。
然而，当大家开始学习的时候，我的挑战就来了！
因为书里面所有的案例都是基于我做的案例平台 https://scrape.center/ 的，比如说，https://spa1.scrape.center/ 这个网站就是一个无反爬的服务端渲染的网站，如图所示：
为了确保大家学习的过程中不会遇到什么问题，我必须要保证的是这个网站一定要能稳定正常运行。
这个挑战其实还是蛮大的。
毕竟，某乎之前不经常性地崩掉吗？
而且，我这个网站它也有着自己特殊的定位，它就是让大家来爬的。也就是说，某个时刻，大家的爬虫运行起来了，我的这个网站瞬间需要承受的就是上百上千甚至上万的并发量，我是完全不知道你到底是起了个什么进程来爬我的网站的。
假如说你搞了个 aiohttp 瞬间给我来一个几千并发，那这个还是很难顶的。
那有办法顶吗？
其实还是有办法的。
我这些案例是基于 Vue Django 开发的，如果说我部署的时候采用某种比较传统的部署方式，比如说在某个机器上装个 Python 环境，然后使用 uwsgi、Nginx 来把服务运行起来，小的并发没啥问题，但真的并发量上来了，真的是扛不住的。
主要因为什么？因为这种传统的部署方式没法在短时间内完成扩容。
有什么好的解决办法吗？
现在这个时代，Kubernetes 已经大行其道。里面有很多优秀的设计理念和强大的功能，使得服务的部署、扩容等等操作变得非常简单。
所以，我当时制作这个案例平台的时候也是选用了 Kubernetes Docker 来部署和维护，Kubernetes 是直接使用了腾讯云上的容器服务（TKE），因此我也无需操心一些集群本身的创建、维护等工作，同时这个容器服务还提供了相对齐全的监控、报警等功能，所以一旦出现了什么问题，我就能立马收到告警消息。
现在一共两台机器，每一台是 2 核 CPU、8 G 内存、200M 带宽，如图所示：
然后我建立了一个 Kubernetes 的 Namespace，叫做 scrape，然后把一个个案例打包成 Docker 镜像跑起来。
有些案例是前后端分离的，那可能就包含两个镜像，比如 spa1-backend 和 spa1-frontend，就分别代表 https://spa1.scrape.center/ 网站的前端部分和后端部分，运行起来之后再配置好 Ingress 就好了。
那我怎么实现自动扩容呢？
其实 Kubernetes 里面也自带了自动扩容的功能，叫做 HorizontalPodAutoscaler，利用它我们可以根据一些指标来配置自动扩容，比如说当内存使用率超过 80% 的时候，那就开始扩容，低于 80% 的时候就自动缩容，然后指定一个最小和最大的 Pod 数量。
配置类似如下：
代码语言：javascript复制spec:
maxReplicas: 15
metrics:
- pods:
metricName: k8s_pod_rate_mem_usage_limit
targetAverageValue: "80"
type: Pods
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: spa1-backend
比如这里我就配置了如果内存用量超过 Limit 值的 80% 的时候，那就开始扩容，最大扩到 15 个 Pod，最小是 1 个 Pod，关联的资源就是 spa1-backend，即 https://spa1.scrape.center/ 后端的 API 服务。
当然腾讯云还有更加方便的图形化配置界面，使用非常方便：
刚才我就尝试了下，当并发量上来的时候，内存占用率就上来了，然后接着 Kubernetes 就会给我自动增加一个 Pod，就在很短的时间内完成了扩容。
这样，如果这个网站的并发量上来了，这个网站背后的 Pod 就会自动完成扩容，以此来应对更高的并发量，如果并发量降下来了，Pod 的量就会自动缩容。
下面这张图是这个网站在被高并发爬取和停止爬取后的 Pod 数量变化：
这是时间倒序排序的，可以看到一开始 Pod 的数量从 6 到了 9，然后后面监测到指标（内存占用）降下来了，然后 Pod 数量就又降下来了。
有了这个的支持，我对这个网站的信息更足了。
当然除了配置自动扩容，我还有一些其他的方法来支持更高的并发和更快的加载速度，比如说 CDN、Cache、虚拟节点等等，这里就暂时不展开讲了，准备双十二开个直播专门讲讲，敬请期待。
欢迎大家前来爬取和测试哈，大家也可以帮忙测测看看能承受多大的并发量，如果感觉还是不太行，我会努力把它变得更加高可用的，谢谢～
