为什么线性增加集群量，却无法线性提升效率?

先说下单机器工作：

以 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 源码了，但是功力不够啊...

billlee

2020-01-12 00:33:04 +08:00

是的，规模大了以后 nginx 也可能成为瓶颈。但处理同样数量的并发，uwsgi 消耗的资源要比简单做转发的 nginx 多，所以一台 nginx 机器可以给多台 uwsgi 机器做均衡负载。
规模更大的情况下，会在 nginx 前再加 LVS, 这个就只做网络层的转发，不做缓冲和协议转换了，还可以通过改包，让回包不经过 LVS.
更大的规模下，网络链路都可能成为瓶颈了。这时就会从 anycast 和域名解析上做负载均衡了。