日常生活中，我们免不了要去一些比较拥挤的地方，比如地铁站、火车站、银行等。这些地点都有一个特征，都会设置多个服务点或者入口，大多数情况下，最近的入口会挤满人，而那些距离较远的服务点或者入口来说，人流密度一般会少很多。
其实，网站的建设也是一样的，一般公司网站或者系统都是有好几台甚至更多服务器一起支撑起来的。当用户集中访问网站的时候，如果没有任何机制来疏导用户的访问，完全随机或者就近原则的话，那么就会导致某些服务器的流量很大，而另外的服务器的访问量很小。这不仅严重的浪费了资源，而且还会导致拉长用户访问网站的 RT（响应时间），影响用户体验，更严重的可能直接拖垮那些流量大的服务器。
这时候，我们就需要一个协调者，让这些用户的请求可以均匀的分派到不同的服务器上。这个协调者有很多，今天我们要说的这个协调者就是 Nginx。
目前三大主流“协调者”：LVS、Nginx、HAproxy
什么是Nginx
Nginx（发音同engine x）是一个高性能且轻量级的WEB服务器，其特点是占有内存少，并发能力强。
Nginx 它能做什么？
— 反向代理
— 负载均衡
— HTTP服务器
— 虚拟主机
— ......
静态HTTP服务器
使用 Nginx 充当一个静态的WEB服务器，可以将服务器上的静态文件（如HTML文档、CSS样式、JS脚本、图片）通过 HTTP 协议展现给客户端。
虚拟主机
有的网站，比如自己的个人博客之类的，由于访问量太小，为了节省成本，可以将多个网站部署在同一台服务器上。例如将 www.a.com 和 www.b.com 两个网站部署在同一台服务器上，两个域名解析到同一个IP地址，但是用户通过两个域名却可以打开两个完全不同的网站，互相不影响，就像访问两个服务器一样，这样 Nginx 就将一台服务器变成了两台虚拟主机。
反向代理与负载均衡
反向代理与负载均衡是 Nginx 功能中使用率最高的两个功能，可以说是它的灵魂所在。
作为前端，要了解的 Nginx 用法其实不多，简单看看就好，因为这两个功能在工作当中就够用了。当我们了解完这两个功能之后，我们就可以做很多事情了。
那我们就开始今天的主题吧~
什么是反向代理
有反必有正，在说反向代理之前，我们先来看看什么是正向代理。
正向代理
正向代理是一个位于客户端和原始服务器之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。
正向代理是客户端知道目的服务器在哪里，然后通过代理服务器去访问目标服务器，而目标服务器并不知道客户端通过什么来访问的，也不知道是该请求是源于哪个客户端。
在正向代理中，客户端是被代理者 。如果以生产者、消费者模式来区分的话，客户端属于消费者，它不对外提供服务，反而是对外消费服务。
用租房为例，
A(客户端) 想租 C(服务端) 的房子,但是 A(客户端) 由于某些情况不能直接找到 C(服务端) ，而恰恰 B (代理) 认识 C(服务端) ，所以 A(客户端) 找了 B(代理) 帮忙，让 B(代理) 去找 C(服务端) 租了这个房子，然后再把房子给 A(客户端) 使用。
这个过程中 C(服务端) 不认识 A(客户端) 只认识 B(代理) ，而 C(服务端) 并不知道 A(客户端) 租了房子，只知道房子租给了 B(代理)。
反向代理
反向代理是架设在服务端的，以代理服务器来接受 Internet 上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 Internet 上请求的客户端。
在反向代理中，服务端是被代理者，对外提供服务，属于服务提供者。
反向代理的原理也可以用租房的例子来解释：
A(客户端) 想租一个房子，然后通过某些渠道找到了B(代理) ，然后 B(代理) 就把这个房子租给了他。而实际上 C(服务端) 才是房东。B(代理) 是中介，把这个房子租给了 A(客户端)。这个过程中 A(客户端) 并不知道这个房子到底谁才是房东，他都有可能认为这个房子就是 B(代理) 的。
正向代理和反向代理的区别
位置不同
正向代理：架设在客户机和目标主机之间
反向代理：架设在服务器端
代理对象不同
正向代理：代理客户端，服务端不知道实际发起请求的客户端
反向代理：代理服务端，客户端不知道实际提供服务的服务端
安全性不同
正向代理：允许客户端通过它访问任意网站并且隐藏客户端自身，因此必须采取安全措施以确保仅为授权的客户端提供服务
反向代理：对外都是透明的，访问者并不知道自己访问的是哪一个代理
什么是负载均衡
其实前面我们在讲排队的例子的时候，说到将排队的人较平均的分散到各个入口，从而缩短排队时间，提高顾客的体验。这其实就是负载均衡的通俗解释了。
负载均衡（Load Balance），意思是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案。
先看一个没有负载均衡机制的Web架构：
用户的请求直接通过 Internet 发送到了指定服务器，这种架构在用户量集中访问的时候就可能出现问题，例如响应时间长而影响用户的体验，最严重的可能是导致服务器挂掉。这对于个人网站或者小型网站来说，可能影响不是很大，但是对于一直都是大流量的网站来说，这是致命的，哪怕是只挂了几分钟，影响到的也是成千上万的用户。
所以，为了提升网站的各方面能力，大型网站一般会把多台服务器组成一个集群对外提供服务。然而，我们访问网站的入口都是一个的，比如 www.a.com。那么当用户在浏览器输入 www.a.com 的时候如何将用户的请求分发到集群中不同的机器上呢，这就是负载均衡在做的事情。
用户每次访问，都会保证服务器集群中的每个服务器压力趋于平衡，分担了服务器压力，避免了服务器崩溃的情况。简言之：哪里“人”少就往哪里去。
即便某个服务器因为某些其他原因挂了，负载均衡策略也会把用户转发到正常工作的服务器上去，从而不影响用户访问。
通常情况下，所有的后端服务器会保证提供相同的内容，以便用户无论哪个服务器响应，都能收到一致的内容。
负载均衡算法
负载均衡服务器在决定将请求转发到具体哪台真实服务器的时候，是通过负载均衡算法来实现的。它是一个负载均衡服务器的核心。
下面是几个常用的算法，这里做个简单介绍：
轮询：为第一个请求选择健康池中的第一个后端服务器，然后按顺序往后依次选择，即第二个请求就发给第二个后端服务器，以此类推，直到最后一个，然后循环。
最小连接：优先选择连接数最少，也就是压力最小的后端服务器，在会话较长的情况下可以考虑采取这种方式。
散列：根据请求源的 IP 的散列（hash）来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器。如果你的应用需要处理状态而要求用户能连接到和之前相同的服务器，可以考虑采取这种方式。
不同的负载均衡服务器会个根据自身的业务需要选择不同的算法，就像电影院和火车站可能会选用不同的引导策略一样。火车站可能会把行李少的旅客分配到一个专门的入口，可能给即将发车的旅客分派到快捷入口，手持可扫描车票的用户单独分配到特殊入口等。
今天所讲的大多都是概念性的东西，具体如何在服务端配置 Nginx，请看下回分享~
