极客专栏《Nginx 核心知识 100 讲》82 小节, 笔记
注意: 这个是看专栏视频, 敲的哈. 这个专栏让我收货蛮大的.
82 | 反向代理与负载均衡原理
第四部分中介绍反向代理与负载均衡, 分为两大块, 先介绍 http 7 层的反向代理, 再介绍 stream 模块提供的 4 层负载均衡. 在介绍反向代理的过程中, 还会按照一种顺序, 一个请求达到 nginx, 转发到上游服务, 在发到客户端, 会按照这一样的流程讲述具体的一个反向代理的工作的过程.
负载均衡
image.PNG
负载均衡是解决服务可用的一个重要手段. 下面看下可扩展性是怎样通过负载均衡来保证的.
image.PNG
我们把自己服务扩容的时候, 最简单方法方法是 x 轴扩展, 我们的服务是无状态的, 无论我们起多少服务, 它们是同等的为用户请求服务的. 这种扩容的成本是最低的. 这就是通常说的水平扩展. 我们希望尽量使用水平扩展来解决问题. 而 nginx 像 Round-Robin,least-connected 是标准的, 基于水平扩展的一个负载均衡算法. 其他算法, 比如 hash 实际上也可以基于水平扩展理论去执行.
水平扩展不能解决所有的问题, 特别是不能解决数据量的问题, 当单台的数据量已经非常大的时候, 无论我扩展多少台服务, 每一台服务的数据仍然非常大. 这时候应该通过另两种解决方案. 比如 Y 轴开始从功能上开始拆分. 拆分了以后, 原先由一台应用服务处理的功能, 分为两台应用服务. 这两台应用服务分别处理不同的 API 即不同的 URL. 这个时候在 nginx 中完全可以通过 location 进行配置, 有些 location 由 proxy 代理到上游的服务中, 而另外一些 URL 代理到另一个集群的 URL 服务中. 我们实现了 Y 轴的扩展.
Y 轴扩展往往需要更改代码, 做大量的重构, 成本比较高. 但是可以解决数据上升问题. 数据量上升可以随着我拆分是可以下降的. 有没有比 Y 轴成本稍低一些, 效果像 x 轴一样容易扩充呢? 我们看 Z 轴.
Z 轴就是基于用户的信息进行扩展, 比如我们可以基于用户的 IP 地址, 就是我们的 CDN. 发现有些 IP 地址靠近 CDN 中心, 把这样的请求引流到这个 CDN 上. 为了分离减小我们数据容量, 可以根据用户名等, 某些固定的用户引流负载均衡到某一个固定的集群. 基于 Z 轴的时候, nginx 提供了很多基于 hash 的一些算法, 它们都可以应用在基于 Z 轴的扩展. 实际上 XYZ, 我们完全可以组合起来应用. 它并不限定只使用一种方法.
反向代理
image.PNG
反向代理分为两类. 一种是四层的, stream 模块才支持的, 相对比较简单, 进来是 UDP/TCP 流量, nginx 转发到上游还是 UDP/TCP 流量. tcp 没有很多业务特性, nginx 并不能做很多工作, 所以相对比较简单. 到了我们应用层, 也就是 7 层就不一样了. http 含有大量跟业务相关的信息, 当客户端发来 http 请求以后, 就可以根据 http header 还有它的 method 的等等参数的信息, 可以转换成不同的协议. 比如: http 进来之后可以转换为 Memcached(根据参数中有的设置为 key 有的设置为 value),scgi,fastcgi 等等
缓存
image.PNG
缓存分为两类, 一种是时间缓存, 一种是空间缓存.
基于时间的缓存: 比如 nginx 的 proxy cache.
基于空间上的缓存: 当我去访问后端服务器一些内容时候, nginx 可以加快速度预取一些响应的内容, 然后放在 nginx 上面. 这个使用比较少.
来源: http://www.jianshu.com/p/fb2734e7b848