【转】关于大型网站技术演进的思考（十八）--网站静态化处理—反向代理（10）

　　反向代理也是一种能够帮助实现网站静态化的重要技术，今天我就来说讲反向代理这个主题。那么首先咱们要了解下什么是反向代理。和反向代理相对应的是正向代理，正向代理也就是咱们常说的代理服务，正向代理是很是常见的，例如在某些公司里咱们想使用互联网，那么咱们就得在浏览器里设置一个代理服务器，经过代理服务器咱们才能正常使用互联网，而这个代理服务器就是一个正向代理服务器。正向代理更加让人熟悉的使用场景估计仍是在FQ技术里的使用，咱们使用一个放置在国外的代理服务器来访问那些在国内没法正常访问的网站，这其实也是在使用一个正向代理服务。

　　其实无论是正向代理仍是反向代理，这两个概念的定义都是以浏览器侧为基准进行的，正向代理是代理浏览器来访问互联网，反向代理是指代理再也不是代理浏览器侧了，而是反过来代理浏览器须要访问的应用服务器。那为何咱们要使用正向代理服务器了？答案固然不是为了FQ了，下面我来列举些实例来讲明这个问题了。

　　例如公司里使用代理服务器主要是为了安全的考虑，不少公司内部都有本身的局域网，通常咱们称之为内网，内网里有公司的各类资源，若是公司员工的电脑随意链接到互联网，假如碰到那些别有用心的黑客，经过攻击员工的工做电脑截取了公司重要的文件资料，那样就会形成公司的重大损失，正向代理除了能防范外部的黑客攻击外还能监控和控制公司内部员工将公司重要文件经过互联网传递给不恰当的人，所以公司让员工使用代理上网基本都是出于安全的角度来考虑的。

　　正向代理的合理使用还能帮助一些企业提高本身产品的核心竞争力，例如在移动端有一款很是流行的浏览器，它之因此很是受用户的欢迎，是由于使用该浏览器上网速度比其余浏览器明显的快多了，那么这款浏览器是如何作到这点的呢？奥秘就是这家公司为本身的浏览器对应创建一个十分强大的代理服务器集群，用户使用该浏览器访问网站时候用户首先访问的是该公司的代理服务器，而这些代理服务器使用缓存技术缓存了海量的网站信息，再加上使用一些web加速的技术例如CDN技术，这就让该浏览器访问网站的效率明显快于其余浏览器。

　　反向代理和正向代理从技术角度上基本上是一致的，区别主要是代理的内容不同了，反向代理代理的是应用服务器。反向代理技术也基本上是互联网公司的一个标配技术，可是反向代理可否正确使用，可否更进一步的发挥它的实用价值，我以为并非全部公司都能作好的，下面我来总结一下反向代理的使用目的吧，具体以下：

　　使用目的一：反向代理能够隐藏真实的应用服务器。该目的属于安全的范畴，反向代理隐藏真实的应用服务器，那么就可让别有用心的黑客很难掌握正确的应用服务器，从而增长黑客的攻击难度。

　　使用目的二：反向代理能够实现负载均衡的功能，例如在java的web开发里有一种很简单的实现集群的手段，这个手段就是使用apache加上tomcat的组合，用户请求先到达前置的apache服务器，apache再使用负载均衡策略将请求分配给后台不一样的tomcat服务器上。

　　使用目的三：反向代理能够起到动态调节应用服务器并发数的目的，通常用做反向代理的服务器都是静态资源服务器，这样的服务器在并发处理能力上要远强于后台的web应用服务器，那么能够经过控制web应用服务器前置的反向代理服务器，这样就能够动态调节后台服务的负载的大小，这个作法的好处可能不少朋友都不太了解，这里我列举个例子，一个网站最须要稳定性的部分是哪一个部分呢？不少朋友会说是数据库，的确数据库是最重要的，由于数据库作分布式很难，很容易造成单点故障，要是数据库挂了基本一切都无法玩了，那么除了数据库以外还有别的吗？固然有，那就是用于处理业务的应用服务器了，应用服务器若是作了集群，集群中其中一台服务器挂了其影响面会比数据库挂掉低多了，可是一个网站的作业务处理的应用服务器挂掉，对公司的损失仍是很大的，而web应用服务器前面的用做反向代理的静态资源服务器挂掉问题就会小多了，至少不会产生公司业务没法正常完成的事情了，所以当网站负载太高，让过载的请求被反向代理拦截或者阻止，这对应用服务器的稳定性提高有莫大的好处。固然反向代理调节应用服务器的负载水平的用途不只仅这些，有兴趣的朋友能够在网络上找找相关的介绍。

　　使用目的四：反向代理能够缓存静态数据，通常用做反向代理的服务器都是使用像apache或者是ngnix这样的静态资源服务器，所以咱们能够把web应用里的静态资源缓存在反向代理服务器上，从而达到提高请求处理的速度问题。反向代理的这个功能就和本系列的主题网站静态化处理切合了。

　　分析完反向代理的使用目的后，咱们如今将反向代理应用到项目里，这里应用的一个前置限定就是将反向代理应用到网站静态化的处理之上，首先是第一个应用方式，以下图所示：

 　　第一种反向代理应用方式就是让反向代理和应用服务器一一对应，也就是每台应用服务的部署服务器上都对应部署一台反向代理服务器，这么作有怎样的好处呢？首先咱们来说第一个好处，若是咱们将网页作了动静分离，那么反向代理服务器就能够负责对请求中的静态资源访问进行处理，同时反向代理还能够承担动静资源整合的目的。这里要特别说明下，前文里我说道动静资源会由于咱们使用的动静策略而发生转化，那么有些动态内容在必定条件被转化为静态资源后，咱们能够将这些作了转化的静态资源在服务器上缓存起来，这个时候上图展现的架构模型就会发生变化，以下图所示：

　

　　咱们看到反向代理服务器和应用服务器之间会造成一个cache层，反向代理访问cache层的效率会比直接访问应用服务器要高的多，这等因而给应用服务器作了一个加速操做，同时经过缓存咱们能够减小应用服务器的运算压力，从而达到提高应用服务器性能的目的。之前有朋友问我这么作会不会增长应用服务器的压力，由于一台服务器上部署了两台能够处理web请求的服务器，那么它们之间必定会有发生冲突的时候，不过我想产生冲突确定是咱们没有很好的处理两者关系所致，因此咱们要理清在同一台服务器上部署反向代理和应用服务器后，它们之间的关系究竟是怎样的？

     其实反向代理和应用服务器从物理形态角度上它们是两个不一样的东西，可是两者在逻辑上实际上是一个总体，它们共同完成一个逻辑性的应用服务器的功能，只不过两者由于应用场景不一样而造成了一种分工合做的关系，反向代理服务器主要完成对静态资源请求的处理，而应用服务器则是负责业务逻辑的处理，它们最终造成一个强大的协力使得总体的逻辑性应用服务器的性能获得显著的提高。

     除此以外，这个反向代理还能够发挥动态调节应用服务器的并发数的目的，可是上面的技术方案却没有发挥反向代理的负载均衡以及安全性这两个方面的做用。为了让反向代理四个使用目的获得充分的发挥，那么咱们该如何来作了？

     方法很简单就是把反向代理的部署地点从应用服务器所在的物理服务器上迁移出来，放到一台独立的物理服务器上，可是这个作法会有性能上的损失，同时还会增长整个技术架构的复杂性。为何性能会损失呢？由于原来的反向代理服务器和应用服务器部署在同一个物理服务器上，那么它们之间的通信都是之内存共享的方式进行的，这样的通信效率是很是高，如今换成了经过网络通信进行沟通，而网络通信是IO设备里效率最差，可靠性最差的，所以单独部署反向代理服务器或多或少都会形成必定性能的损失。

    为何说单独部署反向代理会增长整个网站技术架构的复杂性了？咱们把反向代理服务器单独部署，那么单独部署时候咱们还会是使用一一对应的策略吗？先不谈这么作，从技术和业务角度的好处和坏处，但从成本这个考虑就是会让不少公司望而却步，由于这个作法就会致使用于部署应用服务器的成本翻倍的增长，而增长的服务器用于反向代理，这样的作法怎么体会都不是以为物有所值，再说用于反向代理的静态资源服务器自己处理请求的并发能力是普通应用服务器的数百倍，一一对应自己也没有彻底发挥反向代理服务器的潜力，所以最好的解决方法就是把反向代理服务器作成一个反向代理服务器集群，作成集群问题又来，集群里每台反向代理缓存的数据是否是要保持一个同步了？这就比如处理应用服务器的session同步问题，若是真的这么作会不会致使反向代理服务器上缓存大量使用率不高的数据从而致使缓存的利用率不好，同时同步操做自己也会影响到反向代理集群的性能，因此要设计一个好的反向代理集群是一件十分复杂的事情，其实合理的反向代理集群的作法就是在集群里在进行分组，每一个分组应该是和后端的SOA服务相匹配，这个时候反向代理集群的效率才能获得最大的发挥，同时资源利用率也会更加的合理。其实使用反向代理集群方式，也会给生产部署形成麻烦，若是网站进行了静态化处理，那么反向代理须要承担对静态资源的处理操做，这个时候反向代理和对应的应用服务器结合起来才能造成一个完整的应用服务器，可是如今咱们将一个完整的逻辑应用服务器分开部署了，那么当咱们发布新应用的时候就得面临更加复杂的状况，这就增长了部署和运维的风险和难度。

     我如此批评单独部署反向代理的问题，可是我并非说这种作法彻底不可取，而是想告诉你们这种作法实际上是一种高级的作法，可是也是一个复杂的作法，要作好这个集群是很麻烦的一件事情的，我以为只有当咱们的网站业务量和请求量很大的时候，同时原有方案出现了瓶颈时候能够认真考虑反向代理集群方案的实现，不过将反向代理造成集群会给网站的安全性带来莫大的好处，反向代理能够隐藏后台的应用服务器，这种隐藏就是客户端只须要访问代理服务器便可，应用服务器对外都是以反向代理来展现的，可是若是反向代理和应用服务器一一对应，那么恶意黑客找准了某台反向代理服务器后，对这个反向代理服务器进行反复的攻击，那么这个攻击也就等于攻击与之对应的应用服务器，这就致使反向代理隐藏真实应用服务器的做用就没有获得有效的发挥，而集群这块就能够很好的处理这个问题，不过咱们若是以为使用集群代价过高，咱们也有变通的方法，那就是在全部逻辑应用服务器前面再放置一个反向代理服务器，这个反向代理服务器再也不承担缓存的功能，而只是用来作负载均衡和安全处理，这样一一对应的策略安全性也能够获得保证，不过若是公司技术能力好能够考虑使用LVS这种软件化的负载均衡技术方案，假如公司还颇有钱还能够考虑使用更加高级的硬件负载均衡设备例如F5设备。

     若是咱们网站除了使用网站静态化技术还使用了先后端分离技术，固然这个先后端分离技术应该是使用nodejs的先后端分离技术，那么nodejs应该放置在生产部署的什么位置上了？上篇文章里我曾列举了一个nodejs的应用实践场景，在这个实践场景里我曾经提到若是在原有的网站生产架构下引入nodejs会增长一个请求处理环节，而nodejs使用主要是为了知足先后端分离而非增长网站性能，所以增长的环节可能会让请求处理的性能降低，所以我最后提出一种变通手法，就是nodejs项目发布时候编译源代码，而后将编译出的javascript和html文件干脆推移到浏览器端处理，这样就变相造成了前端MVC框架，这个作法老是有点不三不四的意味，假如咱们真的想把nodejs引入到应用生产的网络架构里，咱们不但愿无故的增长请求处理环节，那么最好是让nodejs服务器替换某个部分。按照这个思路思考，那么我以为nodejs在生产的引入最好是和反向代理相关，最简单的方式就是让nodejs和反向代理一一对应，这样就能够很好的下降引入nodejs带来的问题，固然复杂点的就是反向代理集群对应的应用服务器应该是nodejs的应用服务器，而不是用来作业务处理的业务级别的应用服务器。

    无论怎么说，我认为在网站静态化方案里咱们必定要考虑反向代理的运用，若是静态化技术方案里没有反向代理的身影，那么这个网站静态化处理可能很难达到咱们预期的效果。

    好了，今天就写到这里，最后祝你们晚安。

 

原文连接：http://www.cnblogs.com/sharpxiajun/p/4309976.html