反向代理与负载均衡

1.代理和反向代理

1.1 什么是正向代理

​ 我们常说的代理也就是只正向代理，正向代理的过程，它隐藏了真实的请求客户端，服务端不知道真实的客户端是谁，客户端请求的服务都被代理服务器代替来请求，某些科学上网工具扮演的就是典型的正向代理角色。用浏览器访问 http://www.google.com时，被残忍的block，于是你可以在国外搭建一台代理服务器，让代理帮我去请求google.com，代理把请求返回的相应结构再返回给我。

1.2 什么是反向代理

​ 大家都有过这样的经历，拨打10086客服电话，可能一个地区的10086客服有几个或者几十个，你永远都不需要关心在电话那头的是哪一个，叫什么，男的，还是女的，漂亮的还是帅气的，你都不关心，你关心的是你的问题能不能得到专业的解答，你只需要拨通了10086的总机号码，电话那头总会有人会回答你，只是有时慢有时快而已。那么这里的10086总机号码就是我们说的反向代理。客户不知道真正提供服务人的是谁。

​ 反向代理隐藏了真实的服务端，当我们请求www.baidu.com 的时候，就像拨打10086一样，背后可能有成千上万台服务器为我们服务，但具体是哪一台，你不知道，也不需要知道，你只需要知道反向代理服务器是谁就好了，www.baidu.com 就是我们的反向代理服务器，反向代理服务器会帮我们把请求转发到真实的服务器那里去。Nginx就是性能非常好的反向代理服务器，用来做负载均衡。

1.3 反向代理的实现

​ 在计算机世界里，由于单个服务器的处理客户端（用户）请求能力有一个极限，当用户的接入请求蜂拥而入时，会造成服务器忙不过来的局面，可以使用多个服务器来共同分担成千上万的用户请求，这些服务器提供相同的服务，对于用户来说，根本感觉不到任何差别。

反向代理的实现：

1）需要有一个负载均衡设备来分发用户请求，将用户请求分发到空闲的服务器上

2）服务器返回自己的服务到负载均衡设备

3）负载均衡将服务器的服务返回用户

​ 以上的潜台词是：用户和负载均衡设备直接通信，也意味着用户做服务器域名解析时，解析得到的IP其实是负载均衡的IP，而不是服务器的IP，这样有一个好处是，当新加入/移走服务器时，仅仅需要修改负载均衡的服务器列表，而不会影响现有的服务

2.负载均衡

2.1 什么是负载均衡

​ 负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】。

2.2 常见的负载均衡方案

​ 常见互联网分布式架构如上，分为客户端层、反向代理nginx层、站点层、服务层、数据层。可以看到，每一个下游都有多个上游调用，只需要做到，每一个上游都均匀访问每一个下游，就能实现“将请求/数据【均匀】分摊到多个操作单元上执行”。

2.2.1 客户端层->反向代理层

​ 【客户端层】到【反向代理层】的负载均衡，是通过“DNS轮询”实现的：DNS-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问DNS-server，会轮询返回这些ip，保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip，以做到每台nginx的请求分配也是均衡的。

2.2.2 反向代理层->站点层

​ 【反向代理层】到【站点层】的负载均衡，是通过“nginx”实现的。通过修改nginx.conf，可以实现多种负载均衡策略：

1. 轮询（默认）

​ 每个web请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

upstream nginxDemo {
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
}

2. 最少链接

​ web请求会被转发到连接数最少的服务器上。

upstream nginxDemo {
    least_conn;
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
}

3. weight权重

​ 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况，weight默认是1。

#服务器A和服务器B的访问比例为：2-1;比如有3个请求，前两个会访问A，三个访问B，其它规则和轮询一样。
upstream nginxDemo {
    server 127.0.0.1:8081 weight=2; #服务器A
    server 127.0.0.1:8082; #服务器B
}

4. ip_hash

​ 每个请求按访问ip的hash值分配，这样同一客户端连续的Web请求都会被分发到同一服务器进行处理，可以解决session的问题。当后台服务器宕机时，会自动跳转到其它服务器

upstream nginxDemo {
    ip_hash;
    server 127.0.0.1:8081 weight=2; #服务器A
    server 127.0.0.1:8082; #服务器B
}

​ 基于weight的负载均衡和基于ip_hash的负载均衡可以组合在一起使用

5. url_hash(第三方)

​ url_hash是nginx的第三方模块，nginx本身不支持，需要打补丁。

​ nginx按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存服务器、文件服务器、静态服务器时比较有效。缺点是当后端服务器宕机的时候，url_hash不会自动跳转的其他缓存服务器，而是返回给用户一个503错误:

upstream nginxDemo {
    server 127.0.0.1:8081; #服务器A
    server 127.0.0.1:8082; #服务器B
    hash $request_url;
}

6. fair(第三方)

​ 按后端服务器的响应时间来分配请求，响应时间短的优先分配

upstream nginxDemo {
    server 127.0.0.1:8081; #服务器A
    server 127.0.0.1:8082; #服务器B
    fair;
}

2.2.3 站点层->服务层

【站点层】到【服务层】的负载均衡，是通过“服务连接池”实现的。

上游连接池会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务

2.2.4 服务层->数据层

​ 在数据量很大的情况下，由于数据层(db，cache)涉及数据的水平切分，所以数据层的负载均衡更为复杂一些，它分为“数据的均衡”，与“请求的均衡”。

​ 数据的均衡是指：水平切分后的每个服务(db，cache)，数据量是差不多的;

​ 请求的均衡是指：水平切分后的每个服务(db，cache)，请求量是差不多的。

业内常见的水平切分方式有这么几种：

第一种，按照range水平切分

每一个数据服务，存储一定范围的数据，上图为例

user0服务，存储uid范围1-1kw

user1服务，存储uid范围1kw-2kw

这个方案的好处是:

​ (1)规则简单，service只需判断一下uid范围就能路由到对应的存储服务

​ (2)数据均衡性较好

​ (3)比较容易扩展，可以随时加一个uid[2kw,3kw]的数据服务

不足是：请求的负载不一定均衡，一般来说，新注册的用户会比老用户更活跃，大range的服务请求压力会更大。

第二种，按照id哈希水平切分

每一个数据服务，存储某个key值hash后的部分数据，上图为例：

user0服务，存储偶数uid数据

user1服务，存储奇数uid数据

这个方案的好处是：

(1)规则简单，service只需对uid进行hash能路由到对应的存储服务

(2)数据均衡性较好

(3)请求均匀性较好

不足是：

(1)不容易扩展，扩展一个数据服务，hash方法改变时候，可能需要进行数据迁移

2.2.5 总结

​ 负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】。

(1)【客户端层】到【反向代理层】的负载均衡，是通过“DNS轮询”实现的

(2)【反向代理层】到【站点层】的负载均衡，是通过“nginx”实现的

(3)【站点层】到【服务层】的负载均衡，是通过“服务连接池”实现的

(4)【数据层】的负载均衡，要考虑“数据的均衡”与“请求的均衡”两个点，常见的方式有“按照范围水平切分”与“hash水平切分”