先说下单机器工作:
以 Flask 为例:
Flask 是基于 wsgi 协议搭建的 web 后端框架,协议部分由 werkzeug 实现。
从 socket 角度来讲,就是底层开启有 socket 监听服务,服务端监听到请求后,与客户端建立 TCP 连接,从中读取并解析此次请求内容。
werkzeug 再将其打包为 wsgi 协议可接收的形式,也就是传出来两个参数:environ 和 start_response, flask 的 web 应用就基于此实现业务逻辑。
业务处理完,最后再由 werkzeug 中对应 socket 传回 HTTP 响应给客户端。
在整个流程中,socket 是保持连接的,且一直占用一个线程资源。
然后就是我对集群的想法:
以 Nginx+uWSGI+Flask 为例,
其中 nginx 主要作用就是反向代理、负载均衡。
从 socket 角度讲,nginx 挂起监听服务,服务端监听到请求后,建立 TCP 连接。
第一种想法:
在整个 HTTP 请求过程中,socket 连接都还留在 nginx 所在的服务器中
所谓反向代理,负载均衡,就是把解析出来的数据,先打包成 uwsgi 协议可接收的形式,再由 uWSGI 打包为 wsgi 协议可接收的形式,再分发给各个 web 应用进行业务处理。
每一个 web 应用都有能力、有机会处理业务,这就是一种集群把。
如果是我这样想的,那 nginx 实际上就是在分发数据
那限制最高并发连接瓶颈的,不是就 nginx 所在的服务器了吗?
所以线性增加集群量,也无法线性提高效率?
第二种想法:
是关于 websocket 长连接的疑惑
websocket 集群,逻辑上我确实想不通..
只要有调度者角色存在,长连接肯定还是在该角色所在机器上把?
除非,调度者分发的不是数据,而是一个完整的"连接"...
这个可以实现吗,不用 Location 重定向的那种
ps**我知道最好的答案肯定就是手撕 nginx 源码了,但是功力不够啊...
