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

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

负载均衡

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

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

水平扩展不能解决所有的问题，特别是不能解决数据量的问题，当单台的数据量已经非常大的时候，无论我扩展多少台服务，每一台服务的数据仍然非常大。这时候应该通过另两种解决方案。比如Y轴开始从功能上开始拆分。拆分了以后，原先由一台应用服务处理的功能，分为两台应用服务。这两台应用服务分别处理不同的api即不同的URL。这个时候在nginx中完全可以通过location进行配置，有些location 由proxy代理到上游的服务中，而另外一些URL代理到另一个集群的URL服务中。我们实现了Y轴的扩展。

关注 + 转发后，私信关键词 “ 架构 ”

可获取一份Java架构进阶技术精品视频。（高并发+Spring源码+JVM原理解析+分布式架构+微服务架构+多线程并发原理+BATJ面试宝典）

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的高并发处理环境.当然, 对于高并发我指的是每秒数百个请求连接，大多数人不需要了解这些！

假如你太好奇或是想知道那就关注我吧。