HTTP代理服务器的架构
【摘要】 HTTP代理服务器的架构
HTTP架构师一般都会使用很多种复杂的机制来将多个子模块组合建成一个HTTP服务。现在的网络爬虫中，已经形成4种最基本的模式。如果已经编写了用于生成动态内容的网络爬虫Python代码，并且已经选择了某个支持WSGI的API或框架，应该如何将HTTP服务部署到线上呢？
第一步、运行一个使用网络爬虫Python编写的服务器，服务器的代码中可以直接调用WSGI接口。现在最流行的是Green Unicorn（Gunicorn）服务器，不过也有其他已经可以用于生产环境的纯Python服务器。
第二步、配置mod_wsgi并运行Apache，在一个独立的WSFIDaemonProcess中运行Python代码，由mod_wsgi启动守护进程。
第三步、在后端运行一个类似于Gunicorn的Python HTTP服务器（或者支持所选异步框架的任何服务器），然后在前端运行一个既能返回静态文件，又能对Python编写的动态资源服务进行反向代理的Web服务器。
第四步、在最前端运行一个纯粹的反向代理（如Varnish），在该反向代理后端运行Apache或者nginx，在后端运行Python编写的HTTP服务器。这是一个三层的架构。这些反向代理可以分布在不同的地理位置，这样子就能够将离客户端最近的反向代理上的缓存资源返回给发送请求的客户端。
长期以来，对这4个架构的选择主要基于CPython的3个运行时的特性，即解释器占用内存大、解释器运行慢、全局解释器（GIL，Global Interpreter Lock）禁止多个线程同时运行Python字节码。但同时带来了内存中只能载入一定数量的Python实例。IPIDEA支持http、https、socks5源于全球240＋国家地区的高匿IP。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）