Nginx(反向代理服务器)

正向代理

场景：在国内是无法正常使用google.com。如果想要访问google.com，可以购买一台国外的服务器A，此时你和服务器A的网络是相通的。而服务器A又跟google.com相通，此时可以由服务器A代理你（客户端），去访问google.com。这个过程称之为正向代理，服务端（google.com）只需要知道代理服务器的ip，不需要知道客户端的ip。

示例1：

示例2：

结论：正向代理，是用于代理客户端的。

反向代理

场景：当一个服务器接受过多来自客户端的请求时，服务器难以处理和响应这些请求，会使得整个系统性能下降。为了解决这个难题，可以提供多台部署相同应用的服务器，让客户端的请求分别发送到不同的服务器上，这样单机服务器的压力就会降低很多，整体性能便会提升。但是有一个问题，每个服务器ip都是不同的，也就是说客户端的请求要发送到多个不同的ip上。让客户手动指定ip进行请求，这种方式很不明智。首先是客户的随机性，不知道会访问哪台服务器，其次，会造成一部分服务器压力大，一部分服务器几乎没有使用，浪费资源。因此，这里就需要一个角色去代理服务器，让客户端的请求直接发送到这个角色上，由这个角色去分发请求到不同的服务器上。

这个角色就是反向代理服务器。

结论：反向代理，是用于代理服务端的。

负载均衡

场景：反向代理过程中，每台服务器处理来自客户端的请求都应该是均衡的。
原理：使用一个反向代理服务器指向多台部署相同应用的服务器，客户端请求直接向反向代理服务器发起，反向代理服务器根据负载均衡机制，将请求转发到不同的应用服务器上。

nginx提供了以下三种负载均衡机制：

round-robin：请求以循环、轮转的方式分发到服务器
least-connected：下一个请求被分配到拥有最少活动连接数的服务器
ip-hash：使用一个哈希函数，基于客户端ip地址判断下一个请求应该被分发到哪台服务器

循环、轮转负载均衡

round-robin：默认情况下，使用循环、轮转的方式分发请求到服务器
配置示例：

http{
  upstream myapp{
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
  }
  server{
    listen 80;
    location / {
      proxy_pass http://myapp;
    }
  }
}

当不指定负载均衡方式时，默认以round-robin方式实现。所有请求都会被代理到myapp服务器，根据负载均衡机制分发请求。

最少连接负载均衡

least-connected：当一些请求处理的时间比较长时，最少连接负载均衡能够争取到更大的公平。

配置示例：

upstream myapp{
  least-conn;
  server srv1.example.com;
  server srv2.example.com;
  server srv3.example.com;
}

基于ip地址的负载均衡

ip-hash：采用目标地址散列调度（Destination Hashing Scheduling）算法，根据请求的目标ip地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器可用且未超载，则将请求发送带服务器，否则返回空。

配置示例：

upstream myapp{
  ip-hash;
  server srv1.example.com;
  server srv2.example.com;
  server srv3.example.com;
}

不过，Nginx虽然强大，但是还是有很多问题的。
1. 单纯使用Nginx，会造成配置维护成本变高。
2. 单点故障率增加，因为热点服务的访问量很高，如果这个服务的负载均衡服务出现问题，整个服务都会挂点。
因此，可以结合Zookeeper去使用。

Nginx和Zookeeper搭配使用，详情见：https://blog.csdn.net/xiangjai/article/details/56844400

Nginx负载均衡机制