反向代理

• 反向代理服务器介于用户和真实服务器之间，提供请求和响应的中转服务
• 对于用户而言，访问反向代理服务器就是访问真实服务器
• 反向代理可以有效降低服务器的负载消耗，提升效率

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 动静分离

静态资源响应能力很强，动态资源需要业务逻辑计算

一台不够，可以多扩展几台