3.3什么是正向代理?说反向代理之前,目标角色就是用户

4)可以作为反向代理实现负载均衡

3.2 什么是代理?

说到代理,首先要明确一个概念。所谓代理,就是一个代表,一个渠道。

此时涉及到两个角色,一个是委托角色,一个是目标角色。被委托的角色通过这个代理访问目标角色完成一些任务的过程称为代理操作过程;就像生活中的一家店~一位顾客在专卖店买了一双鞋。这家专卖店是代理商,代理商的角色是制造商,目标角色是用户。

3.3 什么是正向代理?

在说反向代理之前,我们先来看看正向代理。正向代理也是大家最常接触到的代理模式。我们将从两个方面来谈谈正向代理的处理方式。从方面和生活上来说,我们来解释一下什么是前向机构。

在当今的网络环境下,如果我们因为技术需要需要访问一些国外的网站,你会发现某个位于国外的网站是无法通过浏览器访问的。这时候大家可能会使用An操作FQ进行访问,FQ的主要方式是找到一个可以访问国外网站的代理服务器,我们向代理服务器发送请求,代理服务器访问国外网站,然后通过访问的数据给我们!

上述代理模型称为前向代理:

1)正向代理最大的特点就是客户端很清楚要访问的服务器地址;

2)服务器只知道请求来自哪个代理服务器,而不知道来自哪个特定客户端;

3)正向代理模式屏蔽或隐藏真实的客户端信息。

看个示意图(我把客户端和转发代理框在一起,属于同一个环境,后面会介绍):

客户端必须设置转发代理服务器。当然前提是要知道转发代理服务器的IP地址和代理程序的端口。

如下图:

总结:前向代理,“是代理客户端,代表客户端发出请求”。它是一个位于客户端和源服务器之间的服务器()。为了从源服务器获取内容,客户端向代理发送请求并指定目标(源服务器),然后代理将请求转发到源服务器,并将获取的内容返回给客户端。客户端必须进行一些特殊设置才能使用转发代理。

正向代理的目的:

1)访问以前无法访问的资源,例如;

2) 可以缓存,加快资源访问;

3)授权客户端访问并上线认证;

4)代理可以记录用户访问记录(上网行为管理),对外隐藏用户信息。

3.4 什么是反向代理?

了解了什么是正向代理,我们继续看如何处理反向代理。

比如我大帝国的某宝网站,每天同一时间访问该网站的访问量呈爆炸式增长,单台服务器远远不能满足人们日益增长的购买欲望。这时,出现了一个熟悉的词:分布式部署。

所谓分布式部署,是指部署多台服务器来解决访问人数限制的问题。某宝网站的大部分功能也是直接使用Nginx进行反向代理实现的,封装Nginx等组件后,给出一个高大上的名字:有兴趣的小朋友可以访问官网查看具体信息:.

那么反向代理是通过什么方式实现分布式集群操作的呢?我们先看一个示意图(我把服务器和反向代理放在一起,它们属于同一个环境,后面会介绍),如下图。

通过上图可以清楚地看到:Nginx服务器收到多个客户端向服务器发送的请求后,按照一定的规则分发到后端业务处理服务器进行处理。此时,请求的来源,即客户端,已经明确,但不清楚是哪个服务器处理请求。 Nginx 充当反向代理。

客户端不知道代理的存在,反向代理对外透明,访问者不知道自己在访问代理。因为客户端无需任何配置即可访问。

反向代理,“它充当服务器的代理,代表服务器接收请求”。主要用于服务器集群分布式部署的情况。反向代理隐藏了服务器的信息。

反向代理的作用:

1)为保证内网的安全,通常采用反向代理作为公网访问地址,web服务器为内网;

2)负载均衡,通过反向代理服务器优化网站负载。

典型项目场景:

通常,我们在实际的项目运营中,一个应用场景中很可能存在正向代理和反向代理。正向代理代理客户端请求访问目标服务器,目标服务器为反向简单盈利服务器,反向代理多个真实业务处理服务器。

具体拓扑如下:

3.5 正向编码和反向代理的区别

我截了一张图来说明正向代理和反向代理的区别,如下图。

图示如下:

1)在前向代理中,代理和同属于同一个局域网(图中方框内),隐藏了客户端信息;

2) 在反向代理中,代理和同属于同一个局域网(图中方框内),隐藏服务器信息。

其实Proxy在两个代理中所做的就是代表服务器发送和接收请求和响应,但是从结构上来看,正好是反过来的,所以后面出现的proxy方法就被调用了反向作用。

3.6 Nginx 负载均衡技术

我们明确了所谓代理服务器的概念。接下来,Nginx 将扮演反向代理服务器的角色。它使用什么规则来分发请求?未使用的项目应用场景是否可以控制分配规则?

这里提到的客户端发送的请求数和Nginx反向代理服务器接收到的请求数就是我们所说的负载量。

将请求的数量按照一定的规则分配到不同的服务器进行处理的规则是一个平衡规则。

所以~将服务器收到的请求按照规则进行分配的过程称为负载均衡。

负载均衡 在实际的项目运行过程中硬件负载均衡器 能不能同时带多个应用,有硬件负载均衡和软件负载均衡。硬件负载均衡也叫硬负载,比如F5负载均衡,价格比较贵,成本高,但是数据稳定安全,对性能等有很好的保证。中国移动、中国联通等公司将选择硬负载运营;出于成本原因,更多的公司会选择使用软件负载平衡。软件负载平衡使用现有技术。一种结合主机硬件实现的消息队列分发机制。

Nginx 支持的负载均衡调度算法如下:

1) 轮询(默认,常用):将收到的请求根据权重分配给不同的后端服务器。即使后端服务器在使用过程中宕机,Nginx 也会自动将服务器从队列中移除,不会以任何方式影响请求的接受。这样就可以为不同的后端服务器设置一个权重值()来调整请求在不同服务器上的分配率;权重数据越大,被分配到请求的概率就越大;权重值主要是针对实际工作环境中不同的后端服务器硬件配置进行调整。

2)(常用):每个请求根据发起客户端ip的hash结果进行匹配。在该算法下,具有固定IP地址的客户端将始终访问同一个后端服务器,这也在一定程度上解决了集群部署环境中的共享问题。

3)fair:智能调整调度算法,动态分配后端服务器请求处理时间到响应时间。响应时间短,将处理效率高的服务器分配给概率高、​​响应时间长的请求。处理效率低的服务器分配的请求较少;一种结合前两者优点的调度算法。但需要注意的是,Nginx 默认不支持公平算法。如果你想使用这个调度算法,请安装模块。

4):根据访问的URL的hash结果分配请求。每个请求的 URL 都会指向一个固定的后端服务器,这样可以提高 Nginx 作为静态服务器时的缓存效率。还要注意的是,Nginx 默认不支持这种调度算法。如果要使用,需要安装Nginx hash软件包。

4、Nginx 对 TCP、UDP 的负载均衡支持,4.1 概述

准确的说,对于熟悉Nginx的用户来说,以上章节介绍的内容都是针对Nginx最擅长的Http协议的。这也是Nginx最成功的应用场景。随着 Nginx 的不断升级和演进,开发者期待 Nginx 能够支持低层的 TCP、UDP 以及 HTML5 中才出现的协议。幸运的是,这一切都成真了!

Nginx支持1.3版本的协议反向代理(负载均衡),支持1.9.0版本的TCP协议反向代理(负载均衡)。 1.9.13 开始支持UDP协议反向代理(负载均衡)。

Nginx原则上和UDP或者TCP的反向代理(负载均衡)是一致的,而协议其实就是TCP协议的应用层协议,所以本节我们将Nginx介绍给TCP协议反向代理(负载平衡)支持。

对于经典的 HTTP 协议,Nginx 实际上工作在第七层“应用层”。对于低层的TCP协议,负载均衡就是我们通常所说的“四层负载均衡”,它工作在“网络层”和“传输层”。比如LVS(Linux,Linux )和F5(一种硬件负载均衡设备)也属于“四层负载均衡”。

4.2 TCP负载均衡的实现原理

当Nginx从监听端口接收到新的客户端链接时,立即执行路由调度算法获取需要连接的指定服务IP,然后创建新的上游连接连接到指定服务器。

TCP负载均衡支持Nginx独创的调度算法,包括Round Robin(默认,round-robin调度),hash(选择一致)等,同时调度信息数据也会配合健壮性检测模块进行为每个连接选择合适的目标上游服务器。如果使用Hash负载均衡调度方式,可以使用$( IP)来实现简单的持久化会话(相同客户端IP的连接总是落在同一个服务上)。

与其他模块一样,TCP 模块也支持自定义负载平衡转发权重(配置“=2”),以及用于启动出现故障的上游服务器的向下参数。参数可以限制服务器的TCP连接数,根据服务器的容量设置合适的配置值,特别是在高并发场景下,可以达到过载保护的目的。

Nginx 监控客户端连接和上游连接。一旦收到数据,Nginx 会立即读取并推送到上游连接,不会在 TCP 连接中进行数据检测。 Nginx 维护一个内存缓冲区,用于写入客户端和上游数据。如果客户端或服务器传输大量数据,缓冲区会适当增加内存大小。

当 Nginx 收到任何一方关闭连接的通知,或者 TCP 连接空闲时间超过配置的时间时,连接将被关闭。对于TCP长连接,我们应该选择合适的时间,同时注意的参数,防止过早断开。

4.3 服务健壮性监控

TCP 负载均衡模块支持内置的健壮性检测。如果上游服务器拒绝 TCP 连接的时间超过配置的时间,则视为无效。在这种情况下,Nginx 会立即尝试连接到组中的另一台正常服务器。连接失败信息会记录在Nginx错误日志中。

如果一个服务器反复失败(超出或配置的参数),Nginx 也会踢这个服务器。服务器被踢 60 秒后,Nginx 会偶尔尝试重新连接它以检查它是否恢复正常。如果服务器恢复正常,Nginx 会将其重新加入组中,慢慢增加连接请求的比例。

这个地方“增长缓慢”,因为通常一个服务有“热数据”,也就是说80%以上甚至更多的请求实际上会被阻塞在“热​​数据缓存”中,而处理实际上是执行的请求只有一小部分。机器刚启动时,“热数据缓存”实际上还没有建立。这时候大量的请求爆发性的转发,可能会导致机器无法“承受”而再次挂断。以mysql为例,我们95%以上的mysql查询通常都落在内存缓存中,实际执行的查询并不多。

其实无论是单机还是集群,在高并发请求场景下重启或者切换,都存在这种风险。

解决问题主要有两种方式:

1)请求数逐渐增加,由少到多,逐渐积累热点数据,最终达到正常服务状态;

2)提前准备好“常用”数据,主动“预热”服务。预热完成后,打开服务器访问。

TCP负载均衡的原理与LVS相同。它工作在较低的级别,其性能会比原来的 HTTP 负载均衡高很多。但是,它并不比LVS好。 LVS放在内核模块中,而Nginx工作在用户态,Nginx比较重。

5、Nginx能否实现IM负载均衡? 5.1 概览

从上一节的内容来看硬件负载均衡器 能不能同时带多个应用,Nginx可以实现TCP、UDP、协议的逆向代码(负载均衡)。那么,基于TCP、UDP或协议的IM聊天系统能否通过Nginx直接实现IM负载均衡?

为了回答这个问题,我们先来看看不同长连接场景下的具体数据趋势。

为了描述方便,以下基于TCP、UDP或协议的长连接简称为长连接。

5.2 Nginx 支持的长连接反向代理数据定向能力

对于方便Nginx实现的长连接,数据流如下图所示:

如上图,即:

1)客户端使用Nginx反向代理到长连接服务器;

2)客户端可以与建立连接的长连接服务器进行双向通信(即客户端->长连接服务器,和长连接服务器->客户端两个方向)。

简而言之,Nginx 能够实现的长连接数据定向能力是:

1) to (简称c2s):客户端向长连接服务器发送数据的能力;

2) to (简称s2c):长连接服务器向客户端发送数据的能力。

5.3 IM聊天软件所需的长连接数据移动能力

对于 IM 聊天应用程序,必要的数据移动功能是:

1) to (简称c2s):客户端向长连接服务器发送数据的能力;

2) to (简称s2c):长连接服务器向客户端发送数据的能力;

3) to (简称c2c):客户端向客户端发送数据的能力。

IM聊天应用的三种数据趋势,对应典型的功能逻辑场景:

1) to (简称c2s):通常用于客户端向IM长连接服务器发起命令,如:发起好友请求、发送陌生人聊天消息、发送群聊消息等;

2) to (简称s2c):通常用于服务器主动向客户端推送指令,例如:向客户端中继好友请求、转发陌生人聊天消息、传播群聊消息(给所有群组成员)、系统通知等;

3) to (简称c2c):客户端向客户端发送数据的能力,例如:客户端A向客户端B发送一条普通的好友聊天消息(当然这不是必然是P2P技术实现)。

5.4 结论

显然,如上一节所述,Nginx 实现的 TCP、UDP 或协议的反向代理(负载均衡)只能实现 c2s 和 s2c 两种数据趋势,而 IM 聊天应用必须需要 c2s 和 s2c、C2c ,一共3条新闻动态。对于c2c的数据趋势,显然是IM特有的场景需求。有一个像Nginx这样的通用解决方案来提供它有点牵强。

我们可以得出结论:我们不能直接通过Nginx来实现IM负载均衡。

也就是说,如果可以直接通过Nginx来实现IM的负载均衡,那么IM服务器在处理高并发、高吞吐量的时候,就可以像Http协议一样舒服!

5.5 个例外

但是,对于即时通讯网络关注的另一个技术类别——消息推送系统(或类似系统),完全可以通过Nginx直接实现消息推送的负载均衡,因为恰好消息推送push系统只需要c2s,s2c的两种数据趋势不需要c2c的横向数据交互。

文章来源:http://www.cloud.tencent.com/developer/article/1445754

------本页内容已结束,喜欢请分享------

感谢您的来访,获取更多精彩文章请收藏本站。

© 版权声明
THE END
喜欢就支持一下吧
点赞10 分享