项目模式演变过程
一、单一应用架构（ORM）
Object-Relationl Mapping，它的作用是在关系型数据库和对象之间作一个映射，这样，我们在具体的操作数据库的时候，就不需要再去和复杂的SQL语句打交道，只要像平时操作对象一样操作它就可以了
。
一个项目包含用户模块、产品模块、权限管理模块、订单模块、资金模块等等
（都在一个项目中的那种）比如之前的se基础阶段的彩票系统啊。图书管理系统啊
优势：开发简单、适用于流量小，单一架构集中所有功能，减少部署成本。
缺点：如果规模变大，流量变大，扩展，二次开发维护，维护成本高不利于扩展。
二、垂直应用架构
第一次听说这个东西懵了？什么是垂直应用架构。看各种资料的意思就是分层。没错分层。
controller --service—mapper
比如下图
缺点：垂直架构中，各个项目之间可能存在重复的业务逻辑，业务逻辑需要不断复制。不能复用。
优点：解决了扩容问题，流量可以分散到各个子系统。
三、分布式应用架构（rpc远程服务调用）
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心
RPC(Remote Procedure Call Protocol)：远程过程调用：
两台服务器A、B，分别部署不同的应用a,b。当A服务器想要调用B服务器上应用b提供的函数或方法的时候，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义传达调用的数据。
RPC是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继
续进行。
比如：之前在分布式中模拟使用httpclient调用其他接口。
四、流动计算架构(SOA)
Service-Oriented Architecture 面向服务的架构
随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体系(SOA)，也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架
按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）
分布式的延申就是soa
自我（按照自己的想法来解释）解释：
分布式中的服务如果只有五六个，你采用分布式没问题啊，如果你分布式中的核心有几十个那逻辑之间就很复杂，万一那个核心服务宕机了，还要找半天呀。所以慢慢就提出了soa。面向服务的架构系统。
dubbo + zookeeper 就是SOA架构，SOA架构常用的有两种dubbo、springcloud,
dubbo服务架构
随着技术的发展,我们要对一些业务功能进行更细粒度的拆分,而且我们可能要进行服务间的调用,而不仅仅限于WEB与Service的调用,所以就产生了微服务的架构.
springcloud
目前的理解有限，欢迎大佬指点。非常感谢鸭