| 反向代理与负载均衡原理

第四部分中介绍反向代理与负载均衡,分为两大块,先介绍http 7层的反向代理,再介绍stream模块提供的4层负载均衡。在介绍反向代理的过程中,还会按照一种顺序,一个请求达到nginx,转发到上游服务,在发到客户端,会按照这一样的流程讲述具体的一个反向代理的工作的过程。

负载均衡


负载均衡是解决服务可用的一个重要手段。下面看下可扩展性是怎样通过负载均衡来保证的。


我们把自己服务扩容的时候,最简单方法方法是x轴扩展,我们的服务是无状态的,无论我们起多少服务,它们是同等的为用户请求服务的。这种扩容的成本是最低的。这就是通常说的水平扩展。我们希望尽量使用水平扩展来解决问题。而nginx 像Round-Robin、least-connected是标准的,基于水平扩展的一个负载均衡算法。其他算法,比如hash实际上也可以基于水平扩展理论去执行。

水平扩展不能解决所有的问题,特别是不能解决数据量的问题,当单台的数据量已经非常大的时候,无论我扩展多少台服务,每一台服务的数据仍然非常大。这时候应该通过另两种解决方案。比如Y轴开始从功能上开始拆分。拆分了以后,原先由一台应用服务处理的功能,分为两台应用服务。这两台应用服务分别处理不同的api即不同的URL。这个时候在nginx中完全可以通过location进行配置,有些location 由proxy代理到上游的服务中,而另外一些URL代理到另一个集群的URL服务中。我们实现了Y轴的扩展。给大家推荐一个程序员学习交流群:856443934。群里有分享的视频,还有思维导图群公告有视频,都是干货的,你可以下载来看。主要分享分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频。

Y轴扩展往往需要更改代码,做大量的重构,成本比较高。但是可以解决数据上升问题。数据量上升可以随着我拆分是可以下降的。有没有比Y轴成本稍低一些,效果像x轴一样容易扩充呢?我们看Z轴。

Z轴就是基于用户的信息进行扩展,比如我们可以基于用户的IP地址,就是我们的CDN。发现有些IP地址靠近CDN中心,把这样的请求引流到这个CDN上。为了分离减小我们数据容量,可以根据用户名等,某些固定的用户引流负载均衡到某一个固定的集群。基于Z轴的时候, nginx提供了很多基于hash的一些算法,它们都可以应用在基于Z轴的扩展。实际上XYZ,我们完全可以组合起来应用。它并不限定只使用一种方法。

反向代理


反向代理分为两类。一种是四层的,stream模块才支持的,相对比较简单,进来是UDP/TCP流量,nginx转发到上游还是UDP/TCP流量。tcp没有很多业务特性,nginx并不能做很多工作,所以相对比较简单。到了我们应用层,也就是7层就不一样了。http含有大量跟业务相关的信息,当客户端发来http请求以后,就可以根据http header 还有它的method的等等参数的信息,可以转换成不同的协议。比如:http进来之后可以转换为memcached(根据参数中有的设置为key有的设置为value)、scgi、fastcgi等等

缓存


缓存分为两类,一种是时间缓存,一种是空间缓存。

基于时间的缓存:比如nginx的proxy cache。

基于空间上的缓存:当我去访问后端服务器一些内容时候,nginx可以加快速度预取一些响应的内容,然后放在nginx上面。这个使用比较少。

高并发分流技术Nginx

过去谈过一些关于Nginx的常见问题; 其中有一些是关于如何优化Nginx. 很多Nginx新用户是从Apache迁移过来的,因些他们过去常常调整配置和执行魔术操作来确保服务器高效运行.

有一些坏消息要告诉你, 你不能像Apache一样优化Nginx.它没有魔术配置来减半负载或是让PHP运行速度加快一倍. 高兴的是, Nginx已经优化的非常好了. 当你决定使用Nginx并用apt-get,yum或是make命令安装的时候它就已经进行了最佳优化. (注意那些库经常过期,Wiki的安装页面上通常有最新的库)

就是说,很多影响Nginx行为的参数其默认值并不是完全适合高并发的情况. 我们也要考虑Nginx运行所在的平台,优化我们的操作系统当有一些限制的时候.

总的来说,我们无法优化单个连接的负载时间,但是我们可以确保Nginx的高并发处理环境.当然, 对于高并发我指的是每秒数百个请求连接,大多数人不需要了解这些.假如你太好奇或是想知道那就关注我吧。