反向代理那些事儿

一. 反向代理的概念

既然有反向代理，那么就肯定有正向代理。
先看下什么是正向代理：

其实正向代理我们很多人都在用。比如你想去访问Google或者YouTube，但是直接访问是访问不了的。
这个时候你需要借助VPN或者VPS，其实这个时候，VPN or VPS就是你的代理服务器。

还有一种常见的场景：
公司的网络，一般都会使用代理上网，而不是每个人都直接访问公司外的网络资源。这样的好处是，公司可以对员工的网络访问进行限制，比如不能访问色情网站，比如统一设置网络防火墙，安全相关等等。

什么是反向代理呢？上面的正向代理有个共同点，就是都是客户端使用者设置的代理。你使用VPN，或者公司使用代理，都是访问网络的人去设置的代理。
而反向代理，则是服务器端设置代理。
当你访问某个网站的时候，不会直接访问网站业务的服务器，而是先通过一个代理服务器来访问。
简而言之，正向代理和反向代理如图，可以看到正向代理里，客户端跟代理是在一个网络，反向代理里，服务器端跟代理是在一个网络：

正向代理中，proxy和client同属一个LAN，对server透明；
反向代理中，proxy和server同属一个LAN，对client透明。
实际上proxy在两种代理中做的事都是代为收发请求和响应，不过从结构上来看正好左右互换了下，所以把后出现的那种代理方式叫成了反向代理。（引自知乎某匿名用户）

二. 反向代理的实现

1）需要有一个负载均衡设备来分发用户请求，将用户请求分发到空闲的服务器上
2）服务器返回自己的服务到负载均衡设备
3）负载均衡将服务器的服务返回用户
以上的潜台词是：用户和负载均衡设备直接通信，也意味着用户做服务器域名解析时，解析得到的IP其实是负载均衡的IP，而不是服务器的IP，这样有一个好处是，当新加入/移走服务器时，仅仅需要修改负载均衡的服务器列表，而不会影响现有的服务。（引自知乎车小胖）

三. 反向代理的作用

1. 负载均衡，减轻服务器的压力
2. 方便配置防火墙等安全措施（只需要配置代理服务器，而不需要配置所有业务服务器）
3. 提高访问速度（比如用nginx做反向代理，来处理所有静态页面，nginx后面是tomcat，用来处理动态页面。另外，一般反向代理服务器都有cache）
4. 提高吞吐量（而不是性能）。举例来说，配置nginx反向代理，代理服务器可以并发10000个请求，然后后面有10台tomcat应用服务器，每台处理1000个请求。这样并发的瓶颈就在于代理服务器的并发量，而代理服务器其实没有业务逻辑的处理（没有I/O，不需要访问磁盘，也不需要运算，不用调用第三方接口），而只是接受一个http请求，然后发送给应用服务器，等待应用服务器返回一个结果，再把结果传递给客户端。
   而其实代理服务器的并发量，这时候就主要取决于带宽了，比如你有1M的带宽，每个请求都是10K，那我的最大并发就是100。
   而实际上，因为应用服务器要处理业务逻辑，要读写数据库，磁盘等等等等，实际上并发达不到100。这个时候，代理服务器就用上了，因为我代理服务器的并发基本上取决于带宽，我是可以达到理论值100的啊，然后我后面多配几台应用服务器来支持就好了

关于反向代理作用的第4点，可以参照下面的文字：

反向代理的主要作用是分发请求。
首先我们要了解系统的性能瓶颈在哪里，一般来说网络io速度和内存io接近，都远高于磁盘io。假定一个接口请求返回数据100k（一般没有这么大，只是假定一个方便计算的值），10个并发请求就是1M，那么全双工千兆网卡（现在还有万兆网卡，但成本太高，应用还不广），可以支撑并发10000个请求，开双网卡，理论的上限就是20000个并发请求。
假设我们收到请求马上就返回，那么最高并发数就是我们上面计算的结果，但是，问题在于，应用服务器做不到马上返回，因为它有很多业务逻辑需要执行处理，比如给用户发推送发短信发邮件，本地磁盘写日志，请求数据库增删改查，调用微信的登录接口等等等等，都附加了各个层面的io。
所以第一层的优化，我们会尽量优化应用服务自身，把发推送发短信发邮件的活推到队列，让别的服务器去干。这个一般用内存队列，io很高。
开多线程或者协程的方式异步写日志，但再怎么优化，磁盘io的上限突破不了，这个io很低。
还有更激进的方案，干脆日志也写内存，或者通过内网网络同步到别的服务器上，可以更优化。数据库复用连接池，减少连接和断开的时间开销。查询语句尽量优化，减少等待数据库操作的时间。当然，再怎么优化，一样有个上限。
调用微信的登录接口等外部接口，这个就更难办了，受制于人，除了tcp连接池复用能稍微优化一点点，完全是取决于外部条件。
木桶理论取最短板，所有这些条件里，总有最慢最落后的那个。假如拖后腿的这个，最佳状态也只能优化到支持2000个并发，那就尴尬了，本来能支持20000个请求的系统，只能用到1/10性能。（
当然也可以在dns对应不同ip方式分布请求，但是dns层面的分布更复杂更麻烦，因为dns缓存的原因，请求也不能均匀分布，而且ip地址也是越来越稀缺的资源，没有背景没有后台的，搞这么多ip也不容易啊
）
单个公网ip算一个节点的话，这个节点本来的潜力是响应20000个并发请求，实际在应用层面只能到2000并发，潜力还未发掘啊。
这个时候，就是反向代理起到用武之地的时候了。
首先一个反向代理的服务器抛开所有业务层的东西，只单纯的接下请求再返回，那么可以支持到20000并发了。接下来应用层面谁来处理？找来10个小弟，转发给他们，每人2000正好。这样这个节点系统虽然性价比只有10/11，但是性能潜力好歹挖尽了。
这就是反向代理的作用了。