Spring Cloud五大组件
Spring Cloud是分布式微服务架构的一站式解决方案，在Spring Boot基础上能够轻松搭建微服务系统的架构。
现有Spring Cloud有两代实现：
- 一代：Spring Cloud Netflix，主要由：
Eureka、Ribbon、Feign、Hystrix、Zuul｜Gateway、Config等组件组成。
- 二代：Spring Cloud Alibaba，主要由：
Nacos、Sentinel、Seata等组件组成。
一、服务治理组件
一代的服务治理组件为：Spring Cloud Netflix Eureka，主要负责Spring Cloud的服务发现与服务注册。
二代的服务治理组件为：Spring Cloud Alibaba Nacos，可以将Nacos理解为服务注册中心和配置中心的结合体；可以替换一代组件中的：Eureka、Config。
1.1 Eureka
Eureka采用C/S架构，包含两大组件：
-
Eureka Server：服务注册中心，其他微服务启动时，服务注册到Eureka Server。Eureka Server维护了可用服务列表，存储所有注册到Eureka Server的服务的信息。
自己搭建的Eureka Server服务端：https://gitee.com/Xiaoxinnolabi/my-eureka-server
-
Eureka Client：客户端，也就是微服务集群中的各个微服务。微服务启动后，Eureka Client会向Eureka Server发送心跳（默认周期30S）。Eureka Server在多个心跳周期内（默认90S）没有接收到某个Eureka Client的心跳，则将该Eureka Client从可用服务列表移除。
Eureka实现服务注册与发现的原理：
- 服务注册中心（Register Service）：Eureka Server，提供服务注册和服务发现功能
- 服务提供者（Provider Service）：Eureka Client，服务的提供者，以供应服务给消费者所发现。
- 服务消费者（Consumer Service）：Eureka Client，服务的消费者，从服务注册中心获取服务列表，调用所需服务。
调用所需服务：通过HTTP或者消息中间件远程调用服务提供者提供的服务。
1.2 Nacos
Nacos 英文全称为 Dynamic Naming and Configuration Service，是一个由阿里巴巴团队使用 Java 语言开发的开源项目。
Nacos采用C/S架构，包含两大组件：
- Nacos Server：可以作为服务注册中心、配置中心，帮助Nacos Client实现服务的发现、注册，配置的动态刷新。
- Nacos Client：通过
spring-cloud-starter-alibaba-nacos-discovery，在Nacos Server中实现服务的注册和发现；通过spring-cloud-starter-alibaba-nacos-config，在Nacos Server中实现配置的动态刷新。
Nacos实现服务注册与发现的流程：
- Nacos Server启动
- 服务提供者Nacos Client启动，把
spring.appliction.name服务名注册到Nacos Server
- 服务消费者Nacos Client启动，把
spring.appliction.name服务名注册到Nacos Server，从Nacos Server获取一份服务注册信息（包含所有注册到Nacos Server中的服务的信息）。
- 服务消费者进行服务消费时，通过HTTP或RPC调用所需服务。
Nacos特性：
-
服务发现
支持基于DNS和RPC的服务发现。当服务提供者使用原生SDK、OpenAPI或一个独立的Agent TODO向Nacos注册服务后，服务消费者可以通过HTTP、DNS TODO、API查找、发现服务。
-
服务健康监测
提供对服务的实施健康检查，能够阻止请求发送到不健康主机或服务实例上。提供了健康检查仪表盘，能够根据健康状态管理服务的可用性流量
-
动态配置服务
动态配置服务可以让我们以中心化、外部化和动态化的方式，管理所有环境的应用配置和服务配置。
Nacos 提供了一个简洁易用的 UI 帮助我们管理所有服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助我们更安全地在生产环境中管理配置变更和降低配置变更带来的风险。
-
动态DNS服务
Nacos 提供了动态 DNS 服务，能够让我们更容易地实现负载均衡、流量控制以及数据中心内网的简单 DNS 解析服务。
Nacos 提供了一些简单的 DNS APIs TODO，可以帮助我们管理服务的关联域名和可用的 IP:PORT 列表。
-
服务及其元数据管理
Nacos 能让我们从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及 metrics 统计数据。
二、负载均衡组件
一代的负载均衡组件为：Spring Cloud Ribbon，主要负责Spring Cloud的客户端负载均衡和服务调用工具。
二代的负载均衡组件为：Spring Cloud Ribbon或Spring Cloud LoadBalancer；由于Spring Cloud Ribbon已停止更新，进入维护阶段，因此LoadBalancer是Ribbon新版的解决方案；基于现有市场大部分依旧使用Spring Cloud Ribbon，仅对Spring Cloud Ribbon做介绍。
2.1 Spring Cloud Ribbon
Spring Cloud Ribbon 是一套基于 Netflix Ribbon 实现的客户端负载均衡和服务调用工具。
Ribbon 是 Spring Cloud 体系中最核心、最重要的组件之一。它虽然只是一个工具类型的框架，并不像 Eureka Server（服务注册中心）那样需要独立部署，但它几乎存在于每一个使用 Spring Cloud 构建的微服务中。
负载均衡
将用户请求平摊到多个服务器上，以达到扩展服务器带宽、增强数据处理能力、增加吞吐量、提高网络的可用性和灵活性的目的。
常见负载均衡方式：
-
服务端负载均衡
如常规前后端交互中间件Nginx，在客户端和服务端直接建立一个独立的负载均衡器，负载均衡器记录可用服务器列表，通过心跳机制删除故障节点。
请求从客户端发送时，通过中间件Nginx，按照特定算法（轮询、随机），从可用服务器选择服务端进行转发。
-
客户端负载均衡
客户端负载均衡是将负载均衡逻辑以代码的形式封装到客户端上，即负载均衡器位于客户端。客户端通过服务注册中心（例如 Eureka Server）获取到一份服务端提供的可用服务清单。有了服务清单后，负载均衡器会在客户端发送请求前通过负载均衡算法选择一个服务端实例再进行访问，以达到负载均衡的目的；客户端负载均衡也需要心跳机制去维护服务端清单的有效性，这个过程需要配合服务注册中心一起完成。
Ribbon 就是一个基于 HTTP 和 TCP 的客户端负载均衡器，当我们将 Ribbon 和 Eureka 一起使用时，Ribbon 会从 Eureka Server（服务注册中心）中获取服务端列表，然后通过负载均衡策略将请求分摊给多个服务提供者，从而达到负载均衡的目的。
三、熔断器组件
微服务系统架构中，一个请求往往需要多个服务配合处理完成；当一个服务出现故障时，沿着调用链路导致微服务故障在系统中蔓延，最终导致整个系统的瘫痪，这就是“雪崩效应”。为了能够及时对服务故障进行熔断处理，微服务架构引入了熔断器组件，确保整个系统的服务容错、加强保护机制。
3.1 Spring Cloud Hystrix
Spring Cloud Hystrix 是一款优秀的服务容错与保护组件，也是 Spring Cloud 中最重要的组件之一。
Spring Cloud Hystrix 能够有效地阻止分布式微服务系统中出现联动故障，以提高微服务系统的弹性。Spring Cloud Hystrix 具有服务降级、服务熔断、线程隔离、请求缓存、请求合并以及实时故障监控等强大功能。
四、服务网关组件
在微服务架构中，一个系统往往由多个微服务组成，而这些服务可能部署在不同机房、不同地区、不同域名下。这种情况下，客户端（例如浏览器、手机、软件工具等）想要直接请求这些服务，就需要知道它们具体的地址信息，例如 IP 地址、端口号等。
可以通过服务网关，请求直接到服务网关，再由服务网关根据不同的标识信息将请求转发到微服务实例。
可以在服务网关中处理一些非业务功能的逻辑，例如权限验证、监控、缓存、请求路由等。
常见服务网关实现方案：
- Spring Cloud Gateway
- Spring Cloud Netflix Zuul
- Nginx + Lua
4.1 Spring Cloud Gateway
Spring Cloud GateWay 最主要的功能就是路由转发，而在定义转发规则时主要涉及了以下三个核心概念，如下表。
| 核心概念 |
描述 |
| Route（路由） |
网关最基本的模块。它由一个 ID、一个目标 URI、一组断言（Predicate）和一组过滤器（Filter）组成。 |
| Predicate（断言） |
路由转发的判断条件，我们可以通过 Predicate 对 HTTP 请求进行匹配，例如请求方式、请求路径、请求头、参数等，如果请求与断言匹配成功，则将请求转发到相应的服务。 |
| Filter（过滤器） |
过滤器，我们可以使用它对请求进行拦截和修改，还可以使用它对上文的响应进行再处理。 |
Spring Cloud Gateway 工作流程说明如下：
- 客户端将请求发送到 Spring Cloud Gateway 上。
- Spring Cloud Gateway 通过 Gateway Handler Mapping 找到与请求相匹配的路由，将其发送给 Gateway Web Handler。
- Gateway Web Handler 通过指定的过滤器链（Filter Chain），将请求转发到实际的服务节点中，执行业务逻辑返回响应结果。
- 过滤器之间用虚线分开是因为过滤器可能会在转发请求之前（pre）或之后（post）执行业务逻辑。
- 过滤器（Filter）可以在请求被转发到服务端前，对请求进行拦截和修改，例如参数校验、权限校验、流量监控、日志输出以及协议转换等。
- 过滤器可以在响应返回客户端之前，对响应进行拦截和再处理，例如修改响应内容或响应头、日志输出、流量监控等。
- 响应原路返回给客户端。
总而言之，客户端发送到 Spring Cloud Gateway 的请求需要通过一定的匹配条件，才能定位到真正的服务节点。在将请求转发到服务进行处理的过程前后（pre 和 post），我们还可以对请求和响应进行一些精细化控制。
Predicate 就是路由的匹配条件，而 Filter 就是对请求和响应进行精细化控制的工具。有了这两个元素，再加上目标 URI，就可以实现一个具体的路由了。
五、分布式配置组件
5.1 Spring Cloud Config
在分布式微服务系统中，几乎所有服务的运行都离不开配置文件的支持，这些配置文件通常由各个服务自行管理，以 properties 或 yml 格式保存在各个微服务的类路径下，例如 application.properties 或 application.yml 等。
为了解决这些问题，通常我们都会使用配置中心对配置进行统一管理。市面上开源的配置中心有很多，例如百度的 Disconf、淘宝的 diamond、360 的 QConf、携程的 Apollo 等都是解决这类问题的。Spring Cloud 也有自己的分布式配置中心，那就是 Spring Cloud Config。
Spring Cloud Config 是由 Spring Cloud 团队开发的项目，它可以为微服务架构中各个微服务提供集中化的外部配置支持。
Spring Cloud Config 包含以下两个部分：
- Config Server：也被称为分布式配置中心，它是一个独立运行的微服务应用，用来连接配置仓库并为客户端提供获取配置信息、加密信息和解密信息的访问接口。
- Config Client：指的是微服务架构中的各个微服务，它们通过 Config Server 对配置进行管理，并从 Config Sever 中获取和加载配置信息。
Spring Cloud Config 工作流程如下：
- 开发或运维人员提交配置文件到远程的 Git 仓库。
- Config 服务端（分布式配置中心）负责连接配置仓库 Git，并对 Config 客户端暴露获取配置的接口。
- Config 客户端通过 Config 服务端暴露出来的接口，拉取配置仓库中的配置。
- Config 客户端获取到配置信息，以支持服务的运行。
