单一应用架构-垂直应用架构-分布式应用架构
单一应用架构的话我理解为普通的传统项目SSH、SSM的
分布式的话就是市面上的将服务分布在不同的服务器上
那么这个垂直应用架构是什么呢／
类似MVC结构的框架就属于垂直应用构架
垂直就是指依此依赖关系的组件组成的架构，比如分层，界面表示层依赖业务逻辑，而业务逻辑依赖数据库访问。
多机也可以构成垂直架构，比如ngnix这样的反向代理-应用服务器-数据库服务器，也可以算垂直。
彼此不相互依赖的，那么就是水平，比如将一个项目拆成多个独立的系统，用单点登录组合起来，就是水平架构。
也可以是群集方式的部署，每个节点是平等的。
垂直和水平也可以组合起来，比如说反向代理-应用服务器-数据库服务器中，每一层，又由一组群集构成。
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的 Web 框架(MVC)是关键。
就是分层的概念，将整体应用拆分为多个层，层之间单向依赖并传递数据，已达到完成某项功能的目的。
有两种观点：（1）将单一应用拆分成几个独立的应用，互不干扰。 比如你有一个系统，提供网上商城和会员管理和进销存管理三大模块，你把这些功能写在一个应用里，
就叫单一应用，后来把它拆分成3个应用，分开独立部署，这就是垂直架构。
（2）指代码结构上的分层，比如MVC
我比较倾向于第一个。
垂直应用构架按我的理解应该是将代码各层分开，以SSH为例，分为视图层、action层、service层、dao层，各层之间通过接口之间耦合起来，jsp调用action，action调用service,service调用dao
垂直应用架构指的是所有的模块是集成在一起的，自上而下的依赖，打包时是打包在一起的，也就是最终只有一个可运行的war，API、service都在这个war包里
说使用@requestBody 是错的。
@requestBody 是将前端传过来的json格式参数 转成bean里面的属性。
可以理解成 将json参数转化成java正常使用的的参数
通过对单一应用架构的扩展，将单一应用架构的若干个服务进行垂直拆分成独立的应用。例如用户模块拆分成一个集中的数据库（M）、前端（V）、业务（C）集合，当用户模块访问流量逐渐提升时。可将该应用再进行拆分打包
缺点：全部功能集中在一个工程中，对于大型项目不易扩展及维护、维护成本高、有瓶颈、应用太多不利于管理、每个独立应用中都包含了页面和业务，当页面发生改变时。业务并没有更新，所以页面+业务是无法同步的