Nginx: 反向代理和动静分离概述
反向代理
- 反向代理服务器介于用户和真实服务器之间,提供请求和响应的中转服务
- 对于用户而言,访问反向代理服务器就是访问真实服务器
- 反向代理可以有效降低服务器的负载消耗,提升效率
1 )反向代理的模型
- 现在我们有一个用户和真实服务器(通常在内网,无法直接访问到)
- 我们通常会在中间加一个代理服务器(通常位于整个公司业务系统的边缘节点)
- 边缘节点既能和内网保持连通, 同时还会配置一个公网的一个IP地址
- 能够确保域名可以解析到这台代理服务器上的对应的IP地址
- 从而确保用户请求可以到达我们这台代理服务器
- 这个代理服务器充当的就是一个中间人的角色
- 用户想要去访问后端的代理服务器的地址的时候
- 其实并不知道你真实服务器在哪里
- 它会将request的请求转发给我们的代理服务器
- 代理服务器会再将这样一个请求转发给后端的一个真实服务器
- 真实服务器拿到这样一个请求之后,就拆包找到请求体,请求头
- 进行处理封包后,通过响应给代理服务器
- 代理服务器拿到这样一个包之后,再把这个包传递给用户
- 中间这个代理服务器,它其实相当于就是一个桥梁,起到的就是一个中间人的角色
- 它将 request 或 response 在中间做一层中转
- 而用户是不能够和后端的真实服务器发生任何关联的
- 在用户和真实服务器之间加了一层代理服务器,为什么还能够提升效率呢?
- 多了一层代理,就会多了一些网络的消耗,这个是一定的
- 如果请求量比较少,确实效率会损耗,如果是大请求量和高并发的
- 这种设计会事半功倍
2 )反向代理的优势
- 隐藏真实服务器
- 在内网里部署的一些真实的动态服务器来说,它本身的处理能力是很有限的
- 将它们在内网中隐藏起来,而不让它直接接触到互联网,降低了这种攻击的可能性
- 便于横向扩充后端动态服务
- 一台不够,可以使用多台,便于横向扩充
- 动静分离,提升系统健壮性
- 在后端,动态服务器通常来说它提供的是动态服务
- 而对 Nginx 自身来说,它处理静态服务是比较有优势的
3 )Nginx作为反向代理可支持的协议
-
当用户的请求到达Nginx的时候,Nginx可以反向代理跟后端的应用服务器进行交互
-
从而将动态请求分配给应用服务器,由应用程序服务器来进行处理, 处理完之后再返回给Nginx
-
Nginx 和 应用程序服务器交互的时候,它可以依据哪一些协议来进行工作
-
大致可以把用户来的流量分为从四层和七层这样一个角度来说
- 在四层,也就是我们TCP/UDP传输层所定义的一种协议
- 只能够定位到IP+端口, 它跟很多的应用特性是没有关系的
- 它也无法去判断具体业务的应用特性, 所以, 它能够做的工作并不多
- 那这个时候用户过来的是TCP流量
- Nginx 拿到之后传输给后端的应用服务器也只能是这个TCP流量
- 也需要建立TCP连接,假如说,过来的是UDP流量,Nginx转发给后端应用服务器也是UDP的流量
- 四层它是比较简单的,这个是由stream模块所提供的
- 七层反向代理下支持哪些协议
- 假如说,用户发过来是七层的HTTP协议, 通过HTTP访问Nginx
- Nginx 可以将这一部分HTTP的流量转化为后面这七种不同的协议
- 如果想使用uwsgi跟后端的应用程序服务器进行交互的时候
- 后端的应用程序服务器部署的是用python写的一些外部框架
- 还可以支持这个Google的grpc这样一个框架,可以把HTTP的流量通过一定的转换之后,转换到这个GRPC的流量,发给后端的应用程序服务器
- 还可以转换成 memcached 的这样一些服务,假如说,HTTP请求中有一些特定的header,它可以根据header或者一些请求方法的不同,将对应这样一些header中的某一些参数转换为key,从而以 memcached 的协议的形式跟我们后端的应用程序服务器进行交互
- 也支持基于websocket的协议的这种交互
动静分离
- 动静分离是指在web服务器架构中,将静态页面与动态页面或者静态内容接口
和动态内容接口分开不同系统访问的架构设计方法 - 进而提升整个服务访问性能和可维护性
1 ) 设计模型演进
1.1 动静耦合
并发请求小,前后端耦合
1.2 动静分离
静态资源响应能力很强,动态资源需要业务逻辑计算
一台不够,可以多扩展几台