反向代理是系统设计中常用到的一个概念，是相对于正向代理的一种中介服务，还常常与负载均衡作比较。今天就班门弄斧谈一谈自己的代理体会。
正向代理
先了解一下Reverse Proxy的反义词——正向代理（Forward Proxy）。正向代理是一种特殊的网络服务，允许一个网络终端通过这个服务与另一个网络终端进行非直接的连接。一般情况下，我们说的代理服务就是指正向代理。举个不和谐的例子，科学上网时，我们访问google用的就是正向代理服务。
反向服务
正向服务过于不和谐，我就不展开介绍了。那反向服务又是怎么一回事呢？反向代理为何叫反向代理？ - Tom朱的回答 - 知乎上返有一张很有趣的图（图侵删），它生动地展示了正向代理与反向代理的区别。
正向代理和反向代理最大的区别在于他们的服务边界：正向代理服务器属于互联网客户端，而反向代理服务器则是服务端的一部分。简单来说就是：一个是代理客户端，一个是代理服务器。
再举个现实中的例子就是链家租房和自如租房。链家在整个租房的过程中只扮演介绍人的角色，最终我还是向房东承租住房和家具，所有权归属同一个人；而自如自己就是租客的服务方，至于房东是谁，桌椅板凳的所属，甚至这套房子的产权结构租客并不需要关心。
小结一下；反向代理是一个可以集中调用内部服务，并提供统一接口给公共客户的web服务器。来自客户端的请求先被反向代理服务器转发到可响应请求的服务器，然后代理再把服务器的响应结果返回给客户端。
后端渲染
那现实开发中怎么使用反向代理呢？以某后端渲染框架为例子，看一下它的部署应用：
这个例子比较极端，我把api服务，后端渲染服务和静态资源服务分别部署到了lambda、EC2和S3上。如果直接向三个服务器请求资源，浏览器会遇到同源策略的限制——不同域名、协议或者端口无法直接进行AJAX请求。而反向代理就很轻易地解决了这一类的跨域请求——对浏览器来说它们都源自同一个URL，example.com。
资源请求如下：
浏览器向
example.com请求html，Proxy在请求分发后返回来自EC2后端渲染了的静态html浏览器加载html后发现
<script>里同源（相对路径/static）的js文件，就继续向example.com发起新的资源请求；Proxy根据请求的前缀/static，将其分发至S3；浏览器最后通过反向代理获取了来自于S3的js资源Js加载后开始前端渲染，并再次向服务器请求数据；Proxy根据相同的策略再将api 分发到了lambda里；最后，浏览器拿到数据、完成渲染
某些后端渲染框架还会生成一些额外的js。这个也是在步骤2里同步完成，只需在Proxy添加default(*)指向就可以将这些额外的资源请求dispatch到EC2上。具体不再细谈了。
负载均衡（laod balance）
传统的负载均衡器也具有请求分发的作用，那它和反向代理有什么区别呢？Laod balance（以下简称LB）工作原理如下所示：
通常，LB将流量路由给一组功能相同的服务器。它可以通过硬件或HAProxy等软件来实现流量分发；一般基于取模、轮询、随机等算法路由流量，高级点还会根据加权、负载等等进行调度。
反向代理的分发方式就大相径庭了，一般根据不同的API分发到不同功能的服务上。说通俗点，反向代理和负载均衡的区别就是条条和块块的区别。
优缺点
反向代理主要有以下好处：
- 增加安全性：隐藏后端服务的信息，设置黑白名单
- 提高可扩展性和灵活性：客户端只能看到反向代理服务器的IP，运维只需通过配置增减服务
- 终结SSL会话：解密传入请求和加密服务器响应；后端服务器就不必完成这些额外的操作
- 压缩、缓存、添加请求头等一些附加功能。
不利之处：
- 增加复杂度
- 延迟
- 单点故障
最著名的反向代理软件就是Nginx；一些api网关服务（如Netflix zuul）也可以通过filter实现类似功能。我这里提一下AWS全家桶里的cloudfront，它也基本包含了上述反向代理的功能，小厂可以直接拿来当穷人版Nginx使用。
总结
反向代理根据客户端的请求，从其关联的一组或多组后端服务器上获取资源，然后再将这些资源返回给客户端；客户端只知道反向代理的IP地址，而不需知道代理服务器身后服务器集群的存在。
最后出一道系统设计题。我们组在做重构，想把某EC2 > K8s > Docker > Tomcat里的一个非核心业务迁移到lambda上。你觉得重构过程中会遇到哪些困难，怎么解决？思路比结论更重要。
