大家先看这个逻辑图
为什么我们要这样去架构我们的一个项目呢？
这样做的话，动态请求要先访问 A，A 转发访问 B，再由 B 返回结果给 A，A 最后又将结果返回给客户端这样是不是很麻烦？
最初开发的时候是这样的。但是业务逐渐扩大之后你回发现！
这样的好处多多！
第一，为负载均衡做准备，因为随着系统的发展壮大，只用一台 B 来处理动态请求显然是是不够的，要有 B1，B2 等等才行。那么基于图 2 的结构，就可以直接扩展 B1，B2，再修改 Nginx 的配置就可以实现 B1 和 B2 的负载均衡。
第二，对于程序开发而言，这种结构的程序撰写和单台主机没有区别。我们假设只用一台 Tomcat 作为服务器，那么凡是静态资源，如图片、CSS 代码，就需要编写类似这样的访问代码：<img src=”{address of A}/a.jpg”>，当静态资源过多，需要扩展出其他的服务器来安放静态资源时，访问这些资源就可能要编写这样的代码：<img src=”{address of C}/a.jpg”>、<img src=”{address of D}/a.jpg”>。可以看到，当服务器进行变更或扩展时，代码也要随之做出修改，对于程序开发和维护来说非常困难。而基于上面的结构，程序都只 要 <img src=”a.jpg”>，无需关心具体放置资源的服务器地址，因为具体的地址 Nginx 为帮您绑定和选择。