1. 单体应用架构（Monolith）
定义：一个归档包（例如war格式或者Jar格式）包含了应用所有功能的应用程序，我们通常称之为单体应用。架构单体应用的方法论，我们称之为单体应用架构，这是一种比较传统的架构风格。
部署：最终部署的时候只有一份war包,其他的以jar包的方式依赖来。
优点：适用小项目，成本低、开发容易、部署容易、成本低。
缺点：代码耦合，编译难，测试难，随着项目代码量的增加，每次更新代码都需要重新整体部署（部署难）。技术受到限制，比如有些技术是不兼容的，如c++和java不能同时存在一个项目中（阻碍技术创新）。
2. 垂直应用架构
定义：网上查到的太多说法，我比较青睐于这种。将单一应用拆分成几个独立的应用，互不干扰。比如你有一个单体应用系统，有用户管理，订单管理，库存管理三大模块，把它拆分成3个应用，分开独立部署，这就是垂直架构。
部署：最终部署的时候相当于多个war包和jar包组合形成。
优点：系统拆分实现了流量分担，解决了高并发问题。可以针对不同模块进行优化。方便水平扩展，负载均衡，容错率提高。系统间相互独立。
缺点：搭建集群之后，实现负载均衡比较复杂。各个应用之间交互比较困难。
3. 分布式面向服务SOA架构（Service-Oriented Architecture）
定义：面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能抽象拆分成一个个服务，服务之间通过简单、精确定义接口进行通讯。Dubbo就是SOA服务治理方案的核心框架。又有个名字叫做服务治理。站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的就是把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。
使用原因：当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
优点：分布式、可重用、扩展灵活、易维护，松耦合，适用于大项目。
缺点：性能有影响。服务的评估、治理、调度。
4. 微服务架构（MicroService）
定义：
优点：
（1）通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成本也将大幅度下降。
（2）微服务遵循着单一原则。微服务之间采用Restful等轻量级协议传输。
缺点：
（1）微服务过多，服务治理成本高，不利于系统维护。
（2）分布式系统开发的技术成本高（容错、分布式事务等）。
5. SOA与微服务的关系
SOA（面向服务的架构）：它是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用。
微服务架构：其实和SOA架构类似，微服务是在SOA上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
6. 微服务架构和SOA架构远程调用区别和联系
1. http相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝每种语言的支持，现在开源中间件，基本最先支持的几个协议都包含RESTful。
2. RPC框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。
7. 分布式中的CAP原理
C：consistency（一致性）即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。
A：Availability（可用性）即服务一直可用，而且是正常响应时间。
P：Partition tolerance（分区容错性）即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。
一个分布式系统中最多只能同事满足这三种中的两种。
参考：
1. 黑马程序员springcloud视频
2. https://www.jianshu.com/p/92ca0bfbd52f
3. https://blog.csdn.net/qq_42917455/article/details/84642339
4. https://blog.csdn.net/w372426096/article/details/80437198
本文章仅用于自我学习，如果涉及到侵权，联系必删，同时也希望读者对文章中的问题提出宝贵的意见。
持续更新！！！