spring cloud 框架介绍，它与微服务架构之间的关系
作者：互联网
本文旨在快速介绍spring cloud框架，涵盖Spring Cloud最重要的特性和模块的相关介绍。
单体应用
我们可以将单体应用程序描述为一个独立的系统，目标是在单个处理单元中解决一系列功能。下图显示了单体应用程序的外观。主要概念是，所有应用程序都被分解为专门用于某些通用设计逻辑的层，例如业务逻辑和数据库层，但所有这些层通常在同一进程中运行，并通过内部方法调用（Java Virtual 内部）相互通信他们运行的机器）。
微服务应用
微服务应用程序具有更复杂的结构。我们可以将微服务系统视为单体系统的演变，其中其主要功能被分成独立的应用程序，每个应用程序都在自己的进程中运行，并且可能在内部分解为如上文所述的单体模式中的层。
下图显示了微服务系统的粗略示例。这是一个过于简化的模式，但它的目的是为了有一个普遍的理解。在图中，我们有一个网关，代表外部世界进入系统的入口，还有一些微服务，每个都在一个单独的节点（硬件或虚拟机）中。
在上图中，每个微服务都使用自己的数据库实例，该实例也在单独的节点中运行。实际上，我们部署单个服务的方式并没有遵循严格的规则，我们可以有一个共享节点来托管数据库，甚至可以有一个节点来托管三个服务，每个服务都在一个单独的进程中运行（我们不在这里讨论关于容器 只是为了保持简单和通用）。
除了特定的部署模式之外，与单体场景相比的主要区别在于我们有许多功能在自己的进程中运行，并且这些功能通常与 REST 或消息传递协议连接，也就是说，它们通过远程调用进行通信，并且它们即“分布式”组件。
这种“分布式”的特性使我们能够独立开发系统的每一部分。通过这种方式，我们可以增强重用逻辑：在此类专用组件中设计干净和健壮的设计会更简单，并且单个部件可以由完全独立的团队开发。不幸的是，这也有一些缺点。
- 我们如何协调这些分布式组件？
- 我们如何以集中和一致的方式处理配置？
为了利用这种新的软件范例，我们需要技术来应对它的主要缺点。云技术的出现提供了一种增强且有效的方法来处理这些问题。这并不意味着微服务是每个问题的解决方案。有时，整体解决方案是更自然的选择。我们可以说，微服务对于大型复杂系统来说可能是一个很好的选择，但对于更简单的系统来说会失去一些吸引力。
Spring Cloud、微服务和 Netflix OSS
Spring Cloud 位于 Spring Boot 框架之上。它自身提供了许多解决方案，并与外部工具集成以应对主要的微服务架构问题。Netflix OSS 是涵盖主要微服务模式的一系列软件解决方案。Spring Cloud 包为这些解决方案提供了一层集成：使用相关的 Spring Boot 启动器依赖项和一些特定配置就足够了。
将依赖关系设置为发布火车
为了简化依赖管理，引入了发布序列的概念。Spring Cloud 是一个模块的集合，每个模块专门针对某些特定功能，并且每个模块都是独立开发的。发布序列标识一组模块版本，这些模块版本被验证为彼此完全兼容。一旦我们选择了要使用的Spring Boot版本，我们必须选择一个与该版本兼容的 Spring Cloud 发布版本，并将其设置在 Maven依赖管理部分：
XML1个 <依赖管理>
2个 <依赖项>
3个 <依赖>
4个 < groupId > org.springframework.cloud </ groupId >
5个 < artifactId > spring-cloud-dependencies </ artifactId >
6个 <版本> 2021.0.5 </版本>
7个 <类型> pom </类型>
8个 <范围>导入</范围>
9个 </依赖>
10个 </依赖项>
11个 </依赖管理>
然后我们就可以在“ dependencies section ”中通过Spring Cloud starters 来设置具体模块的依赖了。依赖管理部分的唯一目的是指定我们要使用的整套模块和相关版本。这样，我们就不必在依赖项部分为单个模块指定任何版本。此 Maven 功能称为BOM（物料清单）。
按照上面的依赖管理设置，如果我们想让我们的应用程序使用Spring Cloud Config模块的特性，我们可以简单地添加一段这样的配置：
XML1个 <依赖项>
2个 <依赖>
3个 < groupId > org.springframework.cloud </ groupId >
4个 < artifactId > spring-cloud-config-server </ artifactId >
5个 </依赖>
6个 </依赖项>
为了避免在从头开始设置应用程序时在 Spring 文档中搜索兼容性矩阵，一种实用的方法是使用 start.spring.io 站点。在那里您可以首先选择 Spring Boot 版本，然后选择所需的 Spring Cloud 模块。
Spring Cloud 和微服务模式
我们在这里列出了微服务架构中涉及的主要模式以及 Spring Cloud 包为它们提供的内容：
- 分布式/版本化配置
- 服务注册和发现
- 路由
- 服务到服务调用
- 负载均衡
- 断路器
- 分布式消息传递
分布式配置
微服务架构的一个重要问题是如何处理配置。由于我们有许多服务，每个服务都在自己的进程中运行，我们可以简单地认为每个服务负责自己的配置。从系统管理的角度来看，这将是一场噩梦。Spring Cloud 提供了自己的解决方案来提供集中配置功能并克服这个问题，名为 Spring Cloud Config。Spring Cloud Config 使用 Git 作为后端存储设施的首选（替代方案是Hashicorp的 Vault ）。Spring Cloud Config 的两个替代方案是Hashicorp 的 Consul 和 Apache ZooKeeper （两者的功能都没有严格限制在分布式配置上）。
服务注册和发现
微服务架构的主要特征之一是服务注册和发现。每个服务都将自己注册到中央服务器（可能分布在多个节点上以实现高可用性）并使用该中央服务器寻找其他服务进行通信。Spring Cloud 提供与 Netflix OSS 工具的集成 尤里卡 . Eureka 有客户端和服务器包。客户端由依赖项提供，spring-cloud-starter-eureka服务器由spring-cloud-starter-eureka-server 依赖项提供。一个实现客户端的服务会使用服务器来注册自己，同时寻找其他已经注册的服务。
分布式日志记录和跟踪
微服务应用程序中的日志记录和跟踪不是微不足道的任务。我们需要以集中的方式收集日志活动，同时提供一些高级方法来跟踪整个系统的服务交互。Spring Cloud Sleuth 库是解决这些问题的一个可用选择。Sleuth 更重要的功能是将跨微服务的所有次级请求关联到触发它们的单个输入请求。因此它收集了一些标识信息涉及的所有日志记录，同时提供了每个请求中涉及的交互的完整图片，包括时间信息。然后可以将此类信息导出到另一个名为 Zipkin 的工具，该工具专门用于分析微服务架构中的延迟问题。
路由
为了在外部世界和我们的微服务系统之间建立通信，我们需要将传入的请求路由到正确的服务。Netflix OSS 解决方案是Zuul，它可以通过spring-cloud-starter-zuulstarter 依赖和相关配置在 Spring 应用程序内部使用。Zuul 可以起到系统 API 网关的作用，也可以作为服务器端的负载均衡器。
服务到服务调用
服务之间通信的主要形式是REST协议。Spring 提供RestTemplate 作为同步客户端来执行 REST 调用（最近的异步替代方案是WebClient）。Spring Cloud 还通过starter 依赖支持 Netflix Feign 作为基于 REST 的客户端。Feign 使用特定的注释来定义将由框架本身实现的接口。spring-cloud-starter-feign
负载均衡
负载均衡是微服务系统必须实现的另一个重要特性。可以使用不同的规则，例如简单的循环法、跳过过载的服务器或使用基于平均响应时间的算法。Spring Cloud可以通过集成来自Netflix OSS的库Ribbon来支持负载均衡。
断路器
微服务系统中的一个常见场景是某些服务故障可能会影响其他服务和整个系统。断路器是一种试图通过定义故障阈值来解决此问题的模式，在该故障阈值之后服务会立即中断其执行并返回某种形式的预定义结果。Hystrix 是实现这种模式的 Netflix OSS 库。要在 Spring Cloud 项目中包含 Hystrix，spring-cloud-starter-hystrix必须使用 Spring Boot starter。
分布式消息
除了服务之间经典的 REST 风格通信之外，我们还可以选择使用消息架构模式。我们可以将整个架构或其中的一部分基于发布/订阅或事件驱动的点对点消息传递。Spring Cloud Stream 包允许我们实现消息驱动的微服务，并集成更流行的消息代理，如RabbitMQ 和Apache Kafka。
结论
微服务架构需要多种模式来克服其固有的复杂性。Spring Cloud 通过自己的实现以及与第三方工具的集成为这些模式提供解决方案。在本文中，我们快速概述了 Spring Cloud 的主要模块。
标签：springcloud,spring框架,微服务 来源：