单体、集群、分布式、SOA、微服务之间的联系与区别

单体、分层架构、集群、分布式、SOA、微服务之间有什么联系和区别?

1、概念提出时间

单体： 60、70年代
分层： 20世纪80年代
集群： 1990年
分布式：1994年
SOA： 1996年
微服务： 2005年

2、概念内容

2.1 单体（传统）架构系统：

在同一台服务器上运行整个系统，客户端可以有多个，他们都将访问同一个终端处理器。

2.2 集群：

集群是一组协同工作的服务集合,一般由两个或者两个以上的服务器组成。在集群中,同样的服务可以由多个服务实体提供。因而当一个节点出现故障时,集群中的另外一个节点就可以自动接管故障节点的资源。

2.2.1两大关键特性：

1、可扩展性：集群的性能不限于单一的服务实体，新的服务实体可以动态地加入到集群，从而增强集群的性能。

2、高可用性：集群通过服务实体冗余使客户端免于轻易遇到out of service的警告。在集群中，同样的服务可以由多个服务实体提供。如果一个服务实体失败了，另一个服务实体会接管失败的服务实体。集群提供的从一个出错的服务实体恢复到另一个服务实体的功能增强了应用的可用性。

2.2.2两大能力：

1、负载均衡：负载均衡能把任务比较均衡地分布到集群环境下的计算和网络资源。

2、错误恢复：由于某种原因，执行某个任务的资源出现故障，另一服务实体中执行同一任务的资源接着完成任务。这种由于一个实体中的资源不能工作，另一个实体中的资源透明的继续完成任务的过程叫错误恢复。

负载均衡和错误恢复都要求各服务实体中有执行同一任务的资源存在，而且对于同一任务的各个资源来说，执行任务所需的信息视图（信息上下文）必须是一样的。

2.2.3两大技术：

1、集群地址：集群由多个服务实体组成，集群客户端通过访问集群的集群地址获取集群内部各服务实体的功能。具有单一集群地址（也叫单一影像）是集群的一个基本特征。维护集群地址的设置被称为负载均衡器。负载均衡器内部负责管理各个服务实体的加入和退出，外部负责集群地址向内部服务实体地址的转换。有的负载均衡器实现真正的负载均衡算法，有的只支持任务的转换。只实现任务转换的负载均衡器适用于支持ACTIVE-STANDBY的集群环境，在那里，集群中只有一个服务实体工作，当正在工作的服务实体发生故障时，负载均衡器把后来的任务转向另外一个服务实体。

2、内部通信：为了能协同工作、实现负载均衡和错误恢复，集群各实体间必须时常通信，比如负载均衡器对服务实体心跳测试信息、服务实体间任务执行上下文信息的通信。

具有同一个集群地址使得客户端能访问集群提供的计算服务，一个集群地址下隐藏了各个服务实体的内部地址，使得客户要求的计算服务能在各个服务实体之间分布。内部通信是集群能正常运转的基础，它使得集群具有均衡负载和错误恢复的能力。

2.2.4集群分类：

1、高可用性集群；

2、高性能计算科学集群；

3、负载均衡集群。

2.2.5集群中其他相关概念：

1、节点：运行Heartbeat进程的一个独立主机,称为节点。节点有主次之分,分别称为主节点和备份节点。每个节点拥有唯一的主机名,并且拥有属于自己的一组资源,例如,磁盘,文件系统,网络地址和应用服务等,主节点上一般运行着一个或者多个应用服务。而备份节点一般处于监控状态。

2、资源：资源时一个节点可以控制的实体,并且当节点宕机发生故障时,这些资源能够被其它节点接管,一般由以下几种
磁盘分区,文件系统，IP地址,应用程序服务,NFS等

3、事件：表示集群中可能发生的事情。如节点系统故障,网络连通故障,网卡故障,应用程序故障灯,这些事件会导致节点的资源发生转移

4、动作：即对事件发生时的响应方式,可以由shell脚本控制。如,当某个节点发送故障后,备份节点将通过事先设定好的执行脚本进行服务的关闭或者启动,进而接管故障节点的资源。

2.3 分层架构：

分层架构是很常见的架构模式，它也叫 N 层架构，通常情况下，N 至少是 2 层。例如，C/S 架构、B/S 架构。常见的是 3 层架构（例如，MVC、MVP 架构）、4 层架构，5 层架构的比较少见，一般是比较复杂的系统才会达到或者超过 5 层，比如操作系统内核架构。分层架构之所以能够较好地支撑系统扩展，本质在于隔离关注点，即每个层中的组件只会处理本层的逻辑。分层时要保证层与层之间的依赖是稳定的，才能真正支撑快速扩展。系统之间仅仅是把表现层、业务层、持久层分离开，可以实现解耦合。

2.4 分布式：

为了解决传统单体服务架构带来的代码数量庞大，迭代测试维护困难，可能因为一处改动测试不到位造成整个服务瘫痪等问题。分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递和协调的系统。简单来说，就是一群独立计算机集合共同对外提供服务，但是对于系统用户来说，就像是一台计算机在提供服务一样。分布式架构是Web和服务层紧紧联系到了一起，一个web层对应一个服务层。比如阿里的Dubbo，还有 Spring 全家桶里的 Spring Cloud，都是解决分布式微服务架构的优秀框架。(面试题：谈谈你对分布式系统的理解)

2.5 SOA架构：

面向服务的架构，又叫服务治理。把应用程序拆分成多个功能模块，不同的功能模块又拆分成多个表现层，多个服务层。表现层和服务层没有耦合关系，表现层可以调用任意一个服务层。每个服务层中包含多个业务逻辑服务，只需要对外提供服务即可。每个表现层也有多个服务，只需接收、返回数据和页面交互。不同服务之间，不同功能模块之间通过相互依赖或者采用 ESB 作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现，来完成相互通信的，最终提供一系列的功能。SOA就是帮助我们把服务之间调用的乱七八糟的关系给治理起来，然后提供一个统一的标准（各系统的协议、地址、交互方式）。以前是服务与服务之间互相交互，现在是只对数据总线(ESB)进行交互，这样系统就变得统一起来。SOA比分布式架构更加解耦合，扩展也更容易。

2.5.1 新的交互方式：

各个功能模块分别根据统一标准向数据总线进行注册，各业务逻辑服务调用其他服务时，我们并不关心如何找到其他服务，我们只找数据总线，数据总线再根据统一标准找其他服务，所以数据总线在这里充当一个只路人的作用。

2.5.2数据总线：

起到调度服务的作用，数据总线不是集成服务，数据总线更新一个调度框架，每个服务需要根据约定向数据总线注册服务。数据总线里面一个key对于一个value，key指的是服务名，value则是服务的调度方式，还有一点需要说明的是，数据总线只是指路人，服务是不经过数据总线的。数据总线还有一些高级应用，比如心跳检测，实现负载均衡等等。

2.5.3 SOA 所解决的核心问题：

1.系统集成：站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】

2.系统的服务化：站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生。目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用；这一步解决的核心问题是【复用】

3.业务的服务化：站在业务的角度，把业务职能抽象成可复用、可组装的服务；把原先职能化的业务架构转变为服务化的业务架构，进一步提升业务的对外服务能力；前面两步都是从技术层面来解决系统调用、系统功能复用的问题。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】

2.6 微服务：

微服务架构风格是一类将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值的开发方式。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。这些服务围绕业务功能建立而成，且凭借自动化部署机制实现独立部署。

2.6.1 特点：

1.应用程序逻辑分为明确定义的职责范围的粒度组件，这些组件相互协调提供解决方案（粒度细、单一职责）

2.每一个组件都有一个小的职责领域，可以完全部署，也就是说一个服务可以跨越多个应用程序复用（独立部署和维护）

3.服务之间通信基于一些基本的原则，比如服务采用http+json这样的轻量级通信协议，在不同服务之间进行数据交换。这样不同服务可以使用不同的技术栈，互不影响（采用轻量级的通信协议作为通信原则、松耦合）

4.拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。（服务可治理，可管控）

3、优缺点

3.1优点

3.1.1 单体架构：

1.应用开发简单 2.易于对应用程序进行大规模的更改 3.测试相对简单直观 4.部署简单明了 5.水平方向扩展容易(集群)

3.1.2 集群：

1、高可伸缩性：服务器集群具有很强的可伸缩性。随着需求和负荷的增长，可以向集群系统添加更多的服务器。在这样的配置中，可以有多台服务器执行相同的应用和数据库操作。

2、高可用性：在不需要操作者干预的情况下，防止系统发生故障或从故障中自动恢复的能力。通过把故障服务器上的应用程序转移到备份服务器上运行，集群系统能够把正常运行时间提高到大于99.9%，大大减少服务器和应用程序的停机时间。

3、高可管理性：系统管理员可以从远程管理一个、甚至一组集群，就好像在单机系统中一样。

3.1.3 分层架构：

1、开发人员可以只关注整个结构中的其中某一层；(分散关注)
2、可以很容易的用新的实现来替换原有层次的实现；（升级容易）
3、可以降低层与层之间的依赖；（松散耦合）
4、有利于标准化；（标准定义）
5、利于各层逻辑的复用。（逻辑复用）

3.1.4 分布式架构：

1、解耦合、系统不同模块之间用接口通信。

2、项目拆分，不同的团队负责不同的子项目

3、利于扩展，增加功能，只需增加子项目，调用其他系统接口就好了。

4、可以灵活的进行分布式部署。

3.1.5 SOA架构：

1、可重用。解决了分布式的缺点。不同的Web层可以共用一个服务层。

2、松耦合。服务请求者到服务提供者的绑定与服务之间是松耦合的，服务请求者不需要知道服务提供者实现的技术细节。

3、明确定义的接口。

4、基于开放标准。

5、更好的适应性和扩展性

3.1.6 微服务：

1**、服务的独立部署：**每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性低。

2**、服务的快速启动：**拆分之后服务启动的速度必然要比拆分之前快很多，因为依赖的库少了，代码量也少了。

3**、更加适合敏捷开发：**敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布。

4**、职责专一，由专门的团队负责专门的服务：**业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。

5**、服务可以动态按需扩容：**当某个服务的访问量较大时，我们只需要将这个服务扩容即可。

6**、代码的复用：**每个服务都提供REST API，所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。

3.2缺点

3.2.1单体架构：

系统难以维护、发生单点故障而引发的雪崩、扩展性差。解决办法：第一，可以使用更高级的硬件来提升性能。随之成本也会越来越高，对于一些中小业务根本无法承受。第二，可以采用集群，把同一个系统部署到多个服务器上，通过反向代理转发客户机请求到后台服务器(具体到哪一台服务器用的是负载均衡策略)，这是水平扩展，相对来说，还是比较划算的。第三，可以采用分布式架构，把整个系统拆分成多个业务，把每个业务当成一个子系统即可。

3.2.2集群：

当应用出现故障需要重新修复运转时，其他服务器会接管该应用的数据区，而这个接管过程却需要消耗一些时间，应用越大，接管时间越长，会造成一定的延误。

3.2.3分层架构：

1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

3.2.4分布式架构：

1、系统不同模块之间交互需要远程通信，接口开发工作量增加

2、各模块有一些通用业务逻辑无法公用，造成代码冗余。

3、一个web层对弈一个服务层。

3.2.5 SOA架构：

1、提升了系统的复杂程度，降低了系统的性能。

2、很多没有太多意义的文件型信息

3、对商业流程的计划要求甚高

4、无法快速扩展

3.2.6微服务：

1、**运维开销及成本增加：**整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。

2、**必须有坚实的DevOps开发运维一体化技能：**开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。

3、**隐式接口及接口匹配问题，带来发布风险：**把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。

4、**代码重复：**某些底层功能需要被多个服务所用，为了避免将“同步耦合”引入到系统中，有时需要向不同服务添加一些代码，这就会导致代码重复。

5、**分布式系统的复杂性：**作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、数据一致性、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。

4、联系和区别

4.1 SOA和微服务

**联系：**微服务是SOA架构样式的一种变体。两者都关注“服务”，都是通过服务的拆分来解决可扩展性问题。

**区别：**本质上不同的地方在于几个核心理念的差异：是否有ESB、服务的粒度、架构设计的目标等。

1、服务粒度：整体上来说，SOA 的服务粒度要粗一些，而微服务的服务粒度要细一些。

2、服务通信：SOA采用了ESB作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现。微服务推荐使用统一的协议和格式，例如，RESTful协议、RPC协议，无须ESB这样的重量级实现。

3、服务交付：SOA对服务的交付并没有特殊要求，因为SOA更多考虑的是兼容已有的系统；微服务的架构理念要求“快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。
4、应用场景：（1）SOA更加适合于庞大、复杂、异构的企业级系统，这也是SOA诞生的背景。这类系统的典型特征就是很多系统已经发展多年，采用不同的企业级技术，有的是内部开发的，有的是外部购买的，无法完全推倒重来或者进行大规模的优化和重构。因为成本和影响太大，只能采用兼容的方式进行处理，而承担兼容任务的就是 ESB。（传统大型企业）（2）微服务更加适合于快速、轻量级、基于Web的互联网系统，这类系统业务变化快，需要快速尝试、快速交付；同时基本都是基于Web，虽然开发技术可能差异很大（例如，Java、C++、.NET 等），但对外接口基本都是提供 HTTP RESTful 风格的接口，无须考虑在接口层进行类似SOA的ESB那样的处理。

4.2 集群和分布式

**联系：**分布式和集群都是用来提高系统效率；分布式和集群通常结合起来使用。

**区别：**1、分布式是指将不同的业务分布到不同的地方。

2、集群是指将几台服务器集中在一起，实在同一个业务。

3、分布式的每一个节点，都可以用来做集群。而集群不一定就是分布式了。

分布式和集群通常结合起来使用，分布式提供了去中心化的能力，可以把系统的不同业务拆分出来，不同的服务器提供不同的业务服务，解决了之前单一入口压力过大问题，但当某个服务器出现问题，此服务器中的业务就失效了。集群提供了高可用性能力，就可以对每个业务构建集群，这样就保证了业务稳定性，集群同时还有很好的扩展性，当某个业务压力过大时，可以对此业务所在集群动态添加服务器，增强此业务的性能。

例如：互联网上访问的人多了，就可以做一个集群，前面放一个响应服务器(Nginx反向代理服务器)，后面几台服务器完成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重(负载均衡策略)，就将任务交给哪台去完成。

4.2.1 数据库集群和分布式数据库集群的区别

以MySQL数据库集群举例。MySQL集群是一个无共享的(shared-nothing)、分布式节点架构的存储方案，其目的是提供容错性和高性能。它采用了NDB Cluster存储引擎，允许在1个群集中运行多个MySQL服务器。多个服务器之间用的是主从复制原理，可以实现数据的一致性和读写分离。

区别：

1**、**数据库集群有的具有单份数据集，有的具有两份或多份相似的数据集，有的具有两份或多份实时一致的数据集，是将几台服务器集中在一起，实现同一数据集业务；而分布式数据库系统往往具有完全不同的数据集，是将几台服务器集中在一起，实现不同数据集的业务。

2、数据库集群往往是同构的系统，要求集群各节点都具有相同的操作系统和数据库系统版本，甚至补丁包的版本也要求保持一致；而分布式数据库系统可以是异构系统，包含不同的操作系统和不同的数据库系统。

3、数据库集群往往建立在高速局域网内，一般在一个网段内；而分布式数据库系统既可以是高速局域网，也可以是跨部门、跨单位的异地远程网络，一般是跨网段，需要路由。

4、数据库集群组织紧密，一台节点跨了，其他节点可以立即顶上，服务保证延续；而分布式数据库组织松散，一个节点跨了，那这个节点的数据服务就不可用了。

5、分布式数据库的数据处理一般需要多个节点分布式执行，协同配合才能出结果；而数据库集群不一定需要分布式协作就能出结果；

6、分布式数据库中的每一个数据节点，为提升高可用和性能，都可以做成数据库集群。

为保证分布式数据库的高可靠、每一个数据节点都做成数据库集群，因此，目前主流的分布式数据库，应该叫分布式数据库集群。

4.3 总结

从时间线可以看出，应用程序随着访问量的增加，逐渐更新。单体结合分层架构不能满足高并发的访问，孕育成分布式架构，SOA架构是对分布式的升级，微服务架构是对SOA架构的再升级。

5、微服务详解

5.1微服务架构设计过程中需要注意的点

1、服务划分过细，服务间关系复杂

2、服务数量太多，团队效率急剧下降

3、调用链太长，性能下降，问题定位困难

4、没有自动化支撑，无法快速交付（自动化测试、自动化部署、自动化监控等）

5、没有服务治理，微服务数量多了后管理混乱（服务路由、服务故障隔离、服务注册与发现等等）

总结微服务设计中需要避免如下几种情况。1、微服务拆分过细，过分强调”small”；2、微服务基础设施不健全，忽略了“automated”；3、微服务并不轻量级，规模大了后，“lightweight”不再适应。

5.2微服务架构最佳实践(来自互联网)

5.2.1方法篇

1、服务粒度的划分

服务粒度的划分是伴随着架构演进进行的，需要考虑当前的人力、物力等来有效的统筹，在项目的初期可以把服务的粒度设计大一点，随着项目的不断壮大，团队的规模不断变大，可以对现有的粗粒度服务进行有效的拆分，逐步的向细粒度服务发展。

2、拆分

在进行服务拆分的时候是有张可寻的，需要根据自己的项目进行设计，并不能一味的按功能、按大小、按人力等去拆分。基本的拆分可以按如下的几种方式进行。

1**）基于业务逻辑进行拆分**。这是最常见的一种拆分方式，将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。基于业务逻辑拆分虽然看起来很直观，但在实践过程中最常见的一个问题就是团队成员对于“职责范围”的理解差异很大，因此根据业务拆分需要权衡当前项目组的情况。

2**）基于可扩展拆分**。将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。稳定的服务粒度可以粗一些，即使逻辑上没有强关联的服务，也可以放在同一个子系统中，例如将“日志服务”和“升级服务”放在同一个子系统中；不稳定的服务粒度可以细一些，但也不要太细，始终记住要控制服务的总数量。这样拆分主要是为了提升项目快速迭代的效率，避免在开发的时候，不小心影响了已有的成熟功能导致线上问题。

3**）基于可靠性拆分**。将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。这样拆分带来下面几个好处：（避免非核心服务故障影响核心服务、核心服务高可用方案可以更简单、能够降低高可用成本）

4**）基于性能拆分**。基于性能拆分和基于可靠性拆分类似，将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。常见的拆分方式和具体的性能瓶颈有关，可以拆分 Web 服务、数据库、缓存等。

5.2.2基础设施篇

大部分人主要关注的是微服务的“small”和“lightweight”特性，但实际上真正决定微服务成败的，恰恰是那个被大部分人都忽略的“automated”。也就是说基础设施在微服务中占据的主导作用。

上图是微服务架构中涉及的基础设施，可以看出建设完善的微服务基础设施是一项庞大的工程，但是并不是中小企业就不能玩转微服务。第一个原因是已经有开源的微服务基础设施全家桶了，例如大名鼎鼎的 Spring Cloud 项目，涵盖了服务发现、服务路由、网关、配置中心等功能；第二个原因是如果微服务的数量并不是很多的话，并不是每个基础设施都是必须的。通常情况下，可以按照下列的优先级来搭建微服务的基础设施：
1、服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
2、接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。
3、自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。
4、服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。
构中涉及的基础设施，可以看出建设完善的微服务基础设施是一项庞大的工程，但是并不是中小企业就不能玩转微服务。第一个原因是已经有开源的微服务基础设施全家桶了，例如大名鼎鼎的 Spring Cloud 项目，涵盖了服务发现、服务路由、网关、配置中心等功能；第二个原因是如果微服务的数量并不是很多的话，并不是每个基础设施都是必须的。通常情况下，可以按照下列的优先级来搭建微服务的基础设施：
1、服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
2、接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。
3、自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。
4、服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。