单体架构
将所有的功能打包到一起并放在一个web容器中运行。所有的模块使用同一个数据库。
特点：
- 所有的功能集成在一个项目工程中。
- 所有的功能打在一个war包部署到服务器。
- 通过部署应用集群和数据库集群来提高系统的性能。
优点：
- 项目架构简单，前期开发成本低，周期短，小型项目的首选。
- 开发效率高，模块之间交互采用本地方法调用。
- 容易部署，运维成本小，直接打包为一个完整的包，拷贝到web容器的某个目录下即可运行。
- 容易测试：1DE都是为开发单个应用设计的、容易测试(在本地就可以启动完整的系统)
缺点：
- 全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。
- 版本迭代速度逐渐变慢，修改一个地方就要将整个应用全部编译、部署、启动，开发及测试周期过长。
- 无法按需伸缩，通过集群的方式来实现水平扩展，无法针对某个业务按需伸缩。
存在的问题
单体架构的服务，服务的粒度抽象为模块化组件，所有组件耦合在一个开发项目中，并且配置和运行在 一个JVM进程中。如果某个模块化组件需要升级上线，则会导致其他没有变更的模块化组件同样上线，在严重情况下，对某个模块化组件的变更，由于种种原因，会导致其他模块化组件出现问题。
什么是集群：
- 把同一个服务部署在多个容器中
- 多台服务器部署相同应用构成一个集群;
- 作用：通过负载均衡设备共同对外提供服务;
垂直架构
特点：
- 按业务垂直拆分成一个一个的单体服务.
- 服务与服务之间的存在数据冗余 ，耦合性较大，如上图中三个项目都存在客户信息。
- 系统之间的接口多为实现数据同步，如上图中三个项目要同步客户信息。
优点：
- 通过垂直拆分，每个子系统变成小型系统，功能简单，前期开发成本低，周期短。
- 每个子系统可按需伸缩。
- 每个子系统可采用不同的技术。
缺点：
- 子系统之间存在数据冗余、功能冗余 ，耦合性高。
- 系统间糯合度变高，调用关系错综复杂，难以维护。
或者说按照业务垂直切分，每个应用都是单体架构，通过API,或者数据同步进行通讯
分布式架构
随着业务的增加，在垂直应用架构中冗余的业务代码越来越多，就需要将冗余的部分抽取出来，统一做成业务层单独处理，变成一个单独的服务，控制层调用不同的业务层服务就能完成不同的业务功能，具体表现就是一个项目拆分成表现层和服务层两个部分，服务层中包含业务逻辑，表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现，这就是分布式架构。
- 优点：抽取公共的功能作为服务层，提高代码复用行。
- 缺点：系统间耦合度变高，调用关系错综复杂，难以维护。
个人理解SOA架构，微服务架构都属于分布式架构的。只是他们的拆分力度不同。
面向服务的SOA架构
另外，在互联网异军突起的环境下，单体架构的服务无法满足对海量用户发起的高并发请求进行处理的需求，无法突破耦合在一起的模块化组件的性能瓶颈，单一进程已经无法满足需求，并且水平扩展的能力也是很有限的。
SOA作为一种面向服务的架构，是一种软件架构设计的模型和方法论。从业务角度来看，一切以最大化“服务”的价值为出发点，SOA利用企业现有的各种软件体系，重新整合并构建起一套新的软件架构。这套软件架构能够随着业务的变化，随时灵活地结合现有服务，组成新软件，共同服务于整个企业的业务体系。简单的理解，我们可以把SOA看作是模块化的组件，每个模块都可以实现独立功能，而不同模块之间的结合则可以提供不同的服务，模块之间的接口遵循统一标准，可以实现低成本的重构和重组。在SOA的技术框架下，可以把杂乱无章的庞大系统整合成一个全面有序的系统，从而增加企业在业务发展过程中应用系统的灵活性，实现最大的IT资产利用率。
面向服务的体系结构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。
是应用服务大到一定时候的必然产物。那么这个时候就涉及到服务的拆分和组合。其实也可以认为SOA是模块化的延伸。服务拆分就需要涉及到高内聚、低耦合。我们在单体架构中的模块化不也是做这个事情的吗？只不过现在需要涉及到被拆分模块可以单独运行。
SOA架构中有两个主要角色：服务提供者和服务消费者。dubbo其实就是典型的SOA实现。
特点：
- 基于SOA的架构思想，将重复公用的功能抽取为组件，以服务的方式向各个系统提供服务。
- 各系统与服务之间采用webservice、rpc等方式进行通信。
- ESB企业服务总线（服务注册/服务调用/路由/负载均衡/事件）作为系统与服务之间通信的桥梁。
优点
SOA的主要优点概括为：IT能够更好更快地提供业务价值（Business Centric）、快速应变能力（Flexibility）、重用（Reusability）
也可以细分为以下几个方面：
- 服务之间通过简单、精确定义的接口进行通信，不涉及底层编程接口和通信模型。
- 粗粒度性：粗粒度服务提供一项特定的业务功能，采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够了。
- 松耦合性：松耦合性要求SOA架构中的不同服务之间应该保持一种松耦合 的关系，也就是应该保持一种相对独立无依赖的关系。这样的好处有两点，首先是具有灵活性，其次当组成整个应用程序的服务内部结构和实现逐步地发生变化时， 系统可以继续地独立存在。而紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时 这种结构就显得非常脆弱。
- 位置透明性：位置透明性要求SOA系统中的所有服务对于其调用者来说都是位置透明的，也就是说，每个服务的调用者只需要知道想要调用的是哪一个服务，但并不需要知道所调用服务的物理位置在哪。
- 协议无关性：协议无关性要求每一个服务都可以通过不同的协议来调用。
微服务架构
微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端webUI，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。在这里不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。
基于SOA架构的思想，为了满足移动互联网对大型项目及多客户端的需求，对服务层进行细粒度的拆分，所拆分的每个服务只完成某个特定的业务功能，比如订单服务只实现订单相关的业务，用户服务实现用户管理相关的业务等等，服务的粒度很小，所以称为微服务架构。
微服务的概念最早源于 Martin Fowler 的一篇文章《 Microservices》。总体来说,微服务是一种架构风格,对于一个大型复杂的业务系统,它的业务功能可以拆分为多个相互独立的微服务,各个微服务之间是松耦合的,通过各种远程协议进行同步/异步通信,各微服务均可以被独立部署、扩/缩容以及升/降级。
特点：
- 服务层按业务拆分为一个一个的微服务。
- 微服务的职责单一
- 对外发布的服务强调了采用HTTP Rest API的方式来进行
- 有利于采用前后端分离架构。
优点：
- 服务拆分粒度更细，有利于资源重复利用，提高开发效率，
- 可以更加精准的制定每个服务的优化方案，按需伸缩。
- 适用于互联网时代，产品迭代周期更短。
缺点：
- 开发的成本比较高。开发的复杂性增加，因为一个业务流程需要多个微服务通过网络交互来完成。
- 涉及到各服务的容错性问题。
- 涉及到数据的一致性问题。
- 涉及到分布式事务问题。
- 涉及到服务调用问题。
- 微服务过多，服务治理成本高，不利于系统维护。
微服务是什么?
微服务架构是团队面对互联网产品爆发式增长的最优选择，要解决的是快速迭代、高可靠和高可用等问题，把复杂度很高的产品拆分成一些较小的模块，并遵循康威定律，每一个模块用5-9个小团队来维护，这样可以减少沟通成本，提高协作效率，更好地实现快速迭代和弹性扩展。
分布式服务架构：基于去中心化的分布式服务框架与技术，考虑系统架构和服务治理;
面向服务架构︰以业务服务的角度和服务总线的方式(一般是WebService与ESB)考虑系统架构和企业IT治理;
微服务架构∶微服务架构可以看做是面向服务架构和分布式服务架构的拓展，使用更细粒度的服务和一组设计准则来考虑大规模的复杂系统架构设计。
分布式服务架构与微服务架构概念的区别与联系：
- 分布式：分散压力。
- 微服务：分散能力。
微服务架构与SOA架构的不同
如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。
大神Martin Fowler提出 微服务 一概念可以说把SOA的理念继续升华，精进了一步。其核心思想是在应用开发领域，使用一系列微小服务来实现单个应用的方式途径，或者说微服务的目的是有效的拆分应用，实现敏捷开发和部署 ，可以是使用不同的编程语言编写。而SOA可能包含的意义更泛一些，更不准确一些。
- 微服务架构比SQA架构会更加的精細，让专业的人去做专业的。
- 目的是提高效率每个服务之间互不影响，微服务架构中，每个服务需要独立部署
- SOA架构中可能数据库存储会发生共享，微服务强调每个服务都是单独数据库，保证每个服务之间互不影响。
微服务架构中职能团队的划分
传统单体架构将系统分成具有不同职责的层次，对应的项目管理也倾向于将大的团队分成不同的职能团队，主要包括:用户交互UI团队、后台业务逻辑处理团队与数据存取ORM团队、DBA团队等。每个团队只对自己分层的职责负责，并对使用方提供组件服务质量保证。如果其中一个模块化组件需要升级、更新，那么这个变更会涉及不同的分层团队，即使升级和变更的改变很小，也需要进行跨团队沟通:
- 需求阶段需要跨团队沟通产品功能，
- 设计阶段需要跨团队沟通设计方案，
- 开发阶段需要跨团队沟通具体的接口定义，
- 测试阶段需要沟通业务回归等事宜，
- 甚至上线都需要跨团队沟通应用的上线顺序 可见在传统的整体架构下，后期的维护成本很高，出现事故的风险很大。
根据康威定律，团队的交流机制应该与架构设计机制相对应。因此，在微服务架构下，职能团队的划分方法是我们首先要考虑的一个核心要素。
康威定律：简单的说就是公司架构决定沟通成本，系统架构决定系统的沟通成本
微服务时代的团队沟通方式如图所示。
微服务架构按照业务的功能进行划分，每个单一的业务功能叫作一个服务，每个服务对应一个独立的职能团队，团队里包含用户交互 UI 设计师、后台服务开发人员、DBA、运营和运维人员。
在传统的整体架构中，软件是有生命周期的，经历需求分析、开发 和测试，然后被交付给运维团队，这时开发团队将会解散，这是对软件 的一个“放手”。而在微服务架构中，提倡运维人员也是服务项目团队的 一员，倡导谁开发、谁维护，实施终生维护制度。
在业务服务的内部实现需要升级或者变更时，团队内的各角色成员 进行沟通即可，而不需要进行跨团队沟通，这大大提高了沟通效率。只有服务之间的接口需要变更时才需要跨部门沟通，如果前期在服务之间 的交互上定义了良好的接口，则接口变更的概率并不大，即使接口模式有变更，也可以通过一定的设计模式和规范来解决