spring cloud:单体架构、集群架构、分布式架构、SOA架构、微服务架构

原文链接：https://www.longkui.site/program/development/spring-cloud1/5728/

1.单体架构
单体架构也称单体应用，是将一个项目全部部署在一台服务器上面，所有服务都由这一台服务器提供。

这是一种比较传统的架构风格，一般把前台后台都放在一起，通过web服务器（tomcat、nginx、Apache、IIS等）把后台服务运行起来，然后对外提供web服务。

以常见的MVC 框架为例，把表示层、业务层、数据访问层和数据库等放在同一个服务器上，然后进行运行。
单体架构的优点是足够简单，部署起来也比较容易。缺点是随着功能的增加，整个项目越来越复杂，修改一处bug就容易造成整个系统的崩溃，而且伸缩性和扩展性受限。
2.集群架构
当用户数量增多时，服务器的压力越来越大，容易容易引起服务器崩溃。

这个时候有人想到了集群的方式，就是将同一份代码部署在不同的服务器上，然后对外提供服务。简单来说就是将单体应用复制了好多份，这样每个单体应该都可以作为其他单体应用的备份，在其中一个单体应用崩溃后，其他单体应用还可以继续提供服务。

集群的优点就是 扩展容易、易部署，无需改动任何的项目代码，只需要新增服务器部署相同的应用并配置好负载均衡，就可以很好的减轻随着业务增量带来的系统压力。

缺点也很明显：业务发展到一定程度，无论再怎么增加节点，整个集群性能提升效果不明显。
3.分布式架构
分布式架构就是多个人协同共同完成一件事。比如，我们的目的是吃饺子。

单体架构就是一个人负责 ”擀皮“、”剁馅“、”包饺子“、”煮饺子“这几个步骤。

集群架构就是多个人，每个人都负责 ”擀皮“、”剁馅“、”包饺子“、”煮饺子“这几个步骤。

分布式还是多个人，但是不是每个都负责四道工序，而是每个人只负责其中一个工序，比如，有的人只负责”擀皮“，有的人只负责”剁馅“等等。

其应用情形有很多种，如果以”吃饺子“为例，可以有以下 比较侠义的 ”吃饺子“模型和 广义的”吃饺子“模型

比如下面这个 侠义的分布式框架，把原有的功能拆解成4部分，每部分都负责自己功能，大家互相不干扰。缺点也很明显， 其中一个节点出问题，其他的节点不能独立完成整个功能。

下面这个图是也是比较常见的 按照垂直拆分的 分布式框架，同样的，如果其中一个节点出了问题，其他节点也不能独立完成任务。所以设计分布式的时候尽量将每个节点的功能独立。

下面这个图是一个广义的分布式架构，可以看出我们有两台服务器可以”擀皮“，一台服务器可以”剁馅“。而且精简业务后发现，”擀皮“和”剁馅“可以同步进行，于是有了下面这样的结构。广义的分布式架构借鉴了集群的思想将每个独立的功能进行集群，而且可以根据系统的访问量决定部署多少台服务器（部分云服务器可以实现动态扩容）

当然，上面这个图也有描述不确切的一点， 同一个功能的数据库应该像集群那样，连接同一个数据库。
4.SOA架构
SOA是Service Oriented Architecture的缩写，面向服务架构，是一种在计算机环境中设计、开发、部署和管理离散模型的方法。在SOA模型中，所有的功能都被定义成了独立的服务，所有的服务通过服务总线（EBS)或流程管理器来连接。它并是一套完整的开发框架，而是一种开发思想。

为了实现这种思想，一般通过Web Service、企业服务总线和服务注册表。

这个地方不对web service、企业服务总线和服务注册表做具体展开。

我们以下面这幅图为例，一个商城服务里拆分出订单服务和支付服务，如下图：

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

5.微服务架构
微服务架构和和SOA架构非常类似，是一个层面的东西，只不过微服务比SOA更加拆分的“彻底化”。

微服务的核心组件一般包括 注册中心、服务网关、服务熔断、分布式配置中心、负载均衡等。