1.单一应用框架（orm系统）
当网站流量很小的时候，就可以使用这种单一的应用框架架构，所有的功能都在一个系统中，如图，下单支付，后台，都在一个系统中。这样可以只部署一个项目，节点少，部署简单。
缺点：这种架构会随着需求的扩大，资源越来越多，随着流量变多，会变得越来越难以维护。系统会看起来很乱。
2.垂直应用框架(MVC)
mvc架构解决了单一系统架构的扩容性问题，能把前后台分离，可以将功能分成多个子系统，前后端分离。流量能够分散到各个子系统当中，且系统的体积可控，一定程度上降低了开发人员之间协同以及维护的成本，提升了开发效率。
缺点：要新建一个系统就得复制很多配置或者代码，相同逻辑代码需要不断的复制，不能复用。
3.分布式应用架构(RPC)
当垂直系统越来越多的时候，系统之间不可避免的会有交互，我们可以将这些核心的业务抽取出来，单独做成一个服务，其他系统要用的时候，直接调这个服务，逐渐形成了稳定的服务中心。
4.流动计算架构(SOA)
随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体系(SOA)，也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架,也就是中间件等。
各个架构所需要注意的点：
单一应用架构：
1.当网站流量很小时，只需要一个应用，将所有的功能都部署在一起，以减少成本和部署的节点，当资源变大时，可以增加机器来提高效率。
2.此时，应该注重对数据库操作的优化。
垂直应用架构：
1.当访问量逐渐加大时，单一应用架构加机器不能满足响应速度了，我们就要拆成几个子系统，但是他们是没有交互的，来提高运行的效率。
2.此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
分布式服务架构 ：
1.当垂直应用架构越来越多时，系统之间总会交互，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
2.此时，应该更注重代码的复用性。
流动计算架构 ：
1.当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
2.此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。
