【Java学习路线之JavaWeb】Spring Cloud教程（非常详细）_java spring cloud

这套 Spring Cloud 教程适用于开发高度可扩展、高性能分布式微服务系统的 Java 研发人员，

本教程以大量示例，讲解了 Spring Cloud 各组件的应用，让读者可以跟着笔者的思维和代码快速理解并掌握 Spring Cloud。

阅读条件

阅读本套 Spring Cloud 教程之前，您应该已经掌握了 Java 基础、Maven、Spring、Spring MVC、MyBatis、Git、RabbitMQ 以及 Spring Boot 等知识。此外，由于本教程中的所有实例都是使用 IntelliJ IDEA 编写编译的，所以您还需要对 IntelliJ IDEA 有基本的了解。

微服务是什么

微服务（MicroServices）最初是由 Martin Fowler 于 2014 年发表的论文 《MicroServices》 中提出的名词，它一经提出就成为了技术圈的热门话题。

微服务，我们可以从字面上去理解，即“微小的服务”，下面我们从“服务”和“微小”两个方面进行介绍。

1. 所谓“服务”，其实指的是项目中的功能模块，它可以帮助用户解决某一个或一组问题，在开发过程中表现为 IDE（集成开发环境，例如 Eclipse 或 IntelliJ IDEA）中的一个工程或 Moudle。
2. “微小”则强调的是单个服务的大小，主要体现为以下两个方面：

• 微服务体积小，复杂度低：一个微服务通常只提供单个业务功能的服务，即一个微服务只专注于做好一件事，因此微服务通常代码较少，体积较小，复杂度也较低。
• 微服务团队所需成员少：一般情况下，一个微服务团队只需要 8 到 10 名人员（开发人员 2 到 5 名）即可完成从设计、开发、测试到运维的全部工作。

微服务架构

微服务架构是一种系统架构的设计风格。与传统的单体式架构（ALL IN ONE）不同，微服务架构提倡将一个单一的应用程序拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间使用轻量级通信机制（通常是 HTTP RESTFUL API）进行通讯。

通常情况下，这些小型服务都是围绕着某个特定的业务进行构建的，每一个服务只专注于完成一项任务并把它做好 ，即“专业的人做专业的事”。

每个服务都能够独立地部署到各种环境中，例如开发环境、测试环境和生产环境等，每个服务都能独立启动或销毁而不会对其他服务造成影响。

这些服务之间的交互是使用标准的通讯技术进行的，因此不同的服务可以使用不同数据存储技术，甚至使用不同的编程语言。

微服务架构 vs 单体架构

在当今的软件开发领域中，主要有两种系统架构风格，那就是新兴的“微服务架构”和传统的“单体架构”。

单体架构是微服务架构出现之前业界最经典的软件架构类型，许多早期的项目采用的也都是单体架构。单体架构将应用程序中所有业务逻辑都编写在同一个工程中，最终经过编译、打包，部署在一台服务器上运行。

在项目的初期，单体架构无论是在开发速度还是运维难度上都具有明显的优势。但随着业务复杂度的不断提高，单体架构的许多弊端也逐渐凸显出来，主要体现在以下 3 个方面：

• 随着业务复杂度的提高，单体应用（采用单体架构的应用程序）的代码量也越来越大，导致代码的可读性、可维护性以及扩展性下降。
• 随着用户越来越多，程序所承受的并发越来越高，而单体应用处理高并发的能力有限。
• 单体应用将所有的业务都集中在同一个工程中，修改或增加业务都可能会对其他业务造成一定的影响，导致测试难度增加。

由于单体架构存在这些弊端，因此许多公司和组织都开始将将它们的项目从单体架构向微服务架构转型。

下面我们就来对比下微服务架构和单体架构到底有什么不同。

不同点	微服务架构	单体架构
团队规模	微服务架构可以将传统模式下的单个应用拆分为多个独立的服务，每个微服务都可以单独开发、部署和维护。每个服务从设计、开发到维护所需的团队规模小，团队管理成本小。	单体架构的应用程序通常需要一个大型团队，围绕一个庞大的应用程序工作，团队管理的成本大。
数据存储方式	不同的微服务可以使用不同的数据存储方式，例如有的用 Redis，有的使用 MySQL。	单一架构的所有模块共享同一个公共数据库，存储方式相对单一。
部署方式	微服务架构中每个服务都可以独立部署，也可以独立于其他服务进行扩展。如果部署得当，基于微服务的架构可以帮助企业提高应用程序的部署效率。	采用单体架构的应用程序的每一次功能更改或 bug 修复都必须对整个应用程序重新进行部署。
开发模式	在采用微服务架构的应用程序中，不同模块可以使用不同的技术或语言进行开发，开发模式更加灵活。	在采用单体架构的应用程序中，所有模块使用的技术和语言必须相同，开发模式受限。
故障隔离	在微服务架构中，故障被隔离在单个服务中，避免系统的整体崩溃。	在单体架构中，当一个组件出现故障时，故障很可能会在进程中蔓延，导致系统全局不可用。
项目结构	微服务架构将单个应用程序拆分为多个独立的小型服务，每个服务都可以独立的开发、部署和维护，每个服务都能完成一项特定的业务需求。	单体架构的应用程序，所有的业务逻辑都集中在同一个工程中。

微服务的特点

微服务具有以下特点：

• 服务按照业务来划分，每个服务通常只专注于某一个特定的业务、所需代码量小，复杂度低、易于维护。
• 每个微服都可以独立开发、部署和运行，且代码量较少，因此启动和运行速度较快。
• 每个服务从设计、开发、测试到维护所需的团队规模小，一般 8 到 10 人，团队管理成本小。
• 采用单体架构的应用程序只要有任何修改，就需要重新部署整个应用才能生效，而微服务则完美地解决了这一问题。在微服架构中，某个微服务修改后，只需要重新部署这个服务即可，而不需要重新部署整个应用程序。
• 在微服务架构中，开发人员可以结合项目业务及团队的特点，合理地选择语言和工具进行开发和部署，不同的微服务可以使用不同的语言和工具。
• 微服务具备良好的可扩展性。随着业务的不断增加，微服务的体积和代码量都会急剧膨胀，此时我们可以根据业务将微服务再次进行拆分；除此之外，当用户量和并发量的增加时，我们还可以将微服务集群化部署，从而增加系统的负载能力。
• 微服务能够与容器（Docker）配合使用，实现快速迭代、快速构建、快速部署。
• 微服务具有良好的故障隔离能力，当应用程序中的某个微服发生故障时，该故障会被隔离在当前服务中，而不会波及到其他微服务造成整个系统的瘫痪。
• 微服务系统具有链路追踪的能力。

微服务框架

微服务架构是一种系统架构风格和思想，想要真正地搭建一套微服务系统，则需要微服务框架的支持。随着微服务的流行，很多编程语言都相继推出了它们的微服务框架，下面我们就来简单列举下。

Java 微服务框架

市面上的 Java 微服务框架主要有以下 5 种：

• Spring Cloud：它能够基于 REST 服务来构建服务，帮助架构师构建出一套完整的微服务技术生态链。
• Dropwizard：用于开发高性能和 Restful 的 Web 服务，对配置、应用程序指标、日志记录和操作工具都提供了开箱即用的支持。
• Restlet： 该框架遵循 RST 架构风格，可以帮助 Java 开发人员构建微服务。
• Spark：最好的 Java 微服务框架之一，该框架支持通过 Java 8 和 Kotlin 创建微服务架构的应用程序。
• Dubbo：由阿里巴巴开源的分布式服务治理框架。

Go 语言微服务框

Go 语言中的微服务框架较少，使用的较多的是 GoMicro，它是一个 RPC 框架，具有负载均衡、服务发现、同步通信、异步通讯和消息编码等功能。

Phyton 微服务框架

Phyton 中的微服务框架主要有 Flask、Falcon、Bottle、Nameko 和 CherryPy 等。

NodeJS微服务框架

Molecular 是一种使用 NodeJS 构建的事件驱动架构，该框架内置了服务注册表、动态服务发现、负载均衡、容错功能和内置缓存等组件。

Spring Cloud是什么

Spring Cloud 是一款基于 Spring Boot 实现的微服务框架。Spring Cloud 源自 Spring 社区，主要由 Pivotal 和 Netflix 两大公司提供技术迭代和维护。

随着微服务的火爆流行，国内外各大互联网公司都相继分享了他们在微服务架构中，针对不同场景出现的各种问题的解决方案和开源框架。

• 服务治理：阿里巴巴开源的 Dubbo 和当当网在其基础上扩展出来的 DubboX、Netflix 的 Eureka 以及 Apache 的 Consul 等。
• 分布式配置管理：百度的 Disconf、Netflix 的 Archaius、360 的 QConf、携程的 Apollo 以及 Spring Cloud 的 Config 等。
• 批量任务：当当网的 Elastic-Job、LinkedIn 的 Azkaban 以及 Spring Cloud 的 Task 等。
• 服务跟踪：京东的 Hydra、Spring Cloud 的 Sleuth 以及 Twitter 的 Zipkin 等。
• ……

以上这些微服务框架或解决方案都具有以下 2 个特点：

• 对于同一个微服务问题，各互联网公司给出的解决方案各不相同。
• 一个微服务框架或解决方案都只能解决微服务中的某一个或某几个问题，对于其他问题则无能为力。

这种情况下，搭建一套微分布式微服务系统，就需要针对这些问题从诸多的解决方案中做出选择，这使得我们不得不将大量的精力花费在前期的调研、分析以及实验上。

Spring Cloud 被称为构建分布式微服务系统的“全家桶”，它并不是某一门技术，而是一系列微服务解决方案或框架的有序集合。它将市面上成熟的、经过验证的微服务框架整合起来，并通过 Spring Boot 的思想进行再封装，屏蔽调其中复杂的配置和实现原理，最终为开发人员提供了一套简单易懂、易部署和易维护的分布式系统开发工具包。

Spring Cloud 中包含了 spring-cloud-config、spring-cloud-bus 等近 20 个子项目，提供了服务治理、服务网关、智能路由、负载均衡、断路器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。

Spring Cloud 并不是一个拿来即可用的框架，它是一种微服务规范，共有以下 2 代实现：

• 第一代实现：Spring Cloud Netflix
• 第二代实现：Spring Cloud Alibaba

这里我们介绍的 Spring Cloud 特指 Spring Cloud 的第一代实现。

Spring Cloud 常用组件

Spring Cloud 包括 Spring Cloud Gateway、Spring Cloud Config、Spring Cloud Bus 等近 20 个服务组件，这些组件提供了服务治理、服务网关、智能路由、负载均衡、熔断器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。

Spring Cloud 的常用组件如下表所示。

Spring Cloud 组件	描述
Spring Cloud Netflix Eureka	Spring Cloud Netflix 中的服务治理组件，包含服务注册中心、服务注册与发现机制的实现。
Spring Cloud Netflix Ribbon	Spring Cloud Netflix 中的服务调用和客户端负载均衡组件。
Spring Cloud Netflix Hystrix	人称“豪猪哥”，Spring Cloud Netflix 的容错管理组件，为服务中出现的延迟和故障提供强大的容错能力。
Spring Cloud Netflix Feign	基于 Ribbon 和 Hystrix 的声明式服务调用组件。
Spring Cloud Netflix Zuul	Spring Cloud Netflix 中的网关组件，提供了智能路由、访问过滤等功能。
Spring Cloud Gateway	一个基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关框架，它使用 Filter 链的方式提供了网关的基本功能，例如安全、监控/指标和限流等。
Spring Cloud Config	Spring Cloud 的配置管理工具，支持使用 Git 存储配置内容，实现应用配置的外部化存储，并支持在客户端对配置进行刷新、加密、解密等操作。
Spring Cloud Bus	Spring Cloud 的事件和消息总线，主要用于在集群中传播事件或状态变化，以触发后续的处理，例如动态刷新配置。
Spring Cloud Stream	Spring Cloud 的消息中间件组件，它集成了 Apache Kafka 和 RabbitMQ 等消息中间件，并通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件之间的隔离。通过向应用程序暴露统一的 Channel 通道，使得应用程序不需要再考虑各种不同的消息中间件实现，就能轻松地发送和接收消息。
Spring Cloud Sleuth	Spring Cloud 分布式链路跟踪组件，能够完美的整合 Twitter 的 Zipkin。

注：Netflix 是美国的一个在线视频网站，它是公认的大规模生产级微服务的杰出实践者，微服务界的翘楚。Netflix 的开源组件已经在其大规模分布式微服务环境中经过了多年的生产实战验证，成熟且可靠。

Spring Boot 和 Spring Cloud 的区别与联系

Spring Boot 和 Spring Cloud 都是 Spring 大家族的一员，它们在微服务开发中都扮演着十分重要的角色，两者之间既存在区别也存在联系。

1. Spring Boot 和 Spring Cloud 分工不同

Spring Boot 是一个基于 Spring 的快速开发框架，它能够帮助开发者迅速搭 Web 工程。在微服务开发中，Spring Boot 专注于快速、方便地开发单个微服务。

Spring Cloud 是微服务架构下的一站式解决方案。Spring Cloud 专注于全局微服务的协调和治理工作。换句话说，Spring Cloud 相当于微服务的大管家，负责将 Spring Boot 开发的一个个微服务管理起来，并为它们提供配置管理、服务发现、断路器、路由、微代理、事件总线、决策竞选以及分布式会话等服务。

2. Spring Cloud 是基于 Spring Boot 实现的

Spring Cloud 是基于 Spring Boot 实现的。与 Spring Boot 类似，Spring Cloud 也为提供了一系列 Starter，这些 Starter 是 Spring Cloud 使用 Spring Boot 思想对各个微服务框架进行再封装的产物。它们屏蔽了这些微服务框架中复杂的配置和实现原理，使开发人员能够快速、方便地使用 Spring Cloud 搭建一套分布式微服务系统。

3. Spring Boot 和 Spring Cloud 依赖项数量不同

Spring Boot 属于一种轻量级的框架，构建 Spring Boot 工程所需的依赖较少。

Spring Cloud 是一系列微服务框架技术的集合体，它的每个组件都需要一个独立的依赖项（Starter POM），因此想要构建一套完整的 Spring Cloud 工程往往需要大量的依赖项。

4. Spring Cloud 不能脱离 Spring Boot 单独运行

Spring Boot 不需要 Spring Cloud，就能直接创建可独立运行的工程或模块。

Spring Cloud 是基于 Spring Boot 实现的，它不能独立创建工程或模块，更不能脱离 Spring Boot 独立运行。

注意：虽然 Spring Boot 能够用于开发单个微服务，但它并不具备管理和协调微服务的能力，因此它只能算是一个微服务快速开发框架，而非微服务框架。

Spring Cloud 版本

Spring Cloud 包含了许多子项目（组件），这些子项目都是独立进行内容更新和迭代的，各自都维护着自己的发布版本号。

为了避免 Spring Cloud 的版本号与其子项目的版本号混淆，Spring Cloud 没有采用常见的数字版本号，而是通过以下方式定义版本信息。

{version.name} .{version.number}

Spring Cloud 版本信息说明如下：

• version.name：版本名，采用英国伦敦地铁站的站名来命名，并按照字母表的顺序（即从 A 到 Z）来对应 Spring Cloud 的版本发布顺序，例如第一个版本为 Angel，第二个版本为 Brixton（英国地名），然后依次是 Camden、Dalston、Edgware、Finchley、Greenwich、Hoxton 等。
• version.number：版本号，每一个版本的 Spring Cloud 在更新内容积累到一定的量级或有重大 BUG 修复时，就会发布一个“service releases”版本，简称 SRX 版本，其中 X 为一个递增的数字，例如 Hoxton.SR8 就表示 Hoxton 的第 8 个 Release 版本。

Spring Cloud 版本选择

在使用 Spring Boot + Spring Cloud 进行微服务开发时，我们需要根据项目中 Spring Boot 的版本来决定 Spring Cloud 版本，否则会出现许多意想不到的错误。

Spring Boot 与 Spring Cloud 的版本对应关系如下表（参考自Spring Cloud 官网）。

Spring Cloud	Spring Boot
2020.0.x （Ilford）	2.4.x, 2.5.x （从 Spring Cloud 2020.0.3 开始）
Hoxton	2.2.x, 2.3.x （从 Spring Cloud SR5 开始）
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x

注意：Spring Cloud 官方已经停止对 Dalston、Edgware、Finchley 和 Greenwich 的版本更新。

除了上表中展示的版本对应关系之外，我们还可以使用浏览器访问 https://start.spring.io/actuator/info，获取 Spring Cloud 与 Spring Boot 的版本对应关系（JSON 版）。

{
   ……
    "bom-ranges":{
        ……
        "spring-cloud":{
            "Hoxton.SR12":"Spring Boot >=2.2.0.RELEASE and <2.4.0.M1",
            "2020.0.4":"Spring Boot >=2.4.0.M1 and <2.5.6-SNAPSHOT",
            "2020.0.5-SNAPSHOT":"Spring Boot >=2.5.6-SNAPSHOT and <2.6.0-M1",
            "2021.0.0-M1":"Spring Boot >=2.6.0.M1 and <2.6.0-SNAPSHOT",
            "2021.0.0-SNAPSHOT":"Spring Boot >=2.6.0-SNAPSHOT"
        },
        ……
    },
 ……
}

Eureka：Spring Cloud服务注册与发现组件（非常详细）

Eureka 一词来源于古希腊词汇，是“发现了”的意思。在软件领域，Eureka 是 Netflix 公司开发的一款开源的服务注册与发现组件。

Spring Cloud 将 Eureka 与 Netflix 中的其他开源服务组件（例如 Ribbon、Feign 以及 Hystrix 等）一起整合进 Spring Cloud Netflix 模块中，整合后的组件全称为 Spring Cloud Netflix Eureka。

Eureka 是 Spring Cloud Netflix 模块的子模块，它是 Spring Cloud 对 Netflix Eureka 的二次封装，主要负责 Spring Cloud 的服务注册与发现功能。

Spring Cloud 使用 Spring Boot 思想为 Eureka 增加了自动化配置，开发人员只需要引入相关依赖和注解，就能将 Spring Boot 构建的微服务轻松地与 Eureka 进行整合。

Eureka 两大组件

Eureka 采用 CS（Client/Server，客户端/服务器） 架构，它包括以下两大组件：

• Eureka Server：Eureka 服务注册中心，主要用于提供服务注册功能。当微服务启动时，会将自己的服务注册到 Eureka Server。Eureka Server 维护了一个可用服务列表，存储了所有注册到 Eureka Server 的可用服务的信息，这些可用服务可以在 Eureka Server 的管理界面中直观看到。
• Eureka Client：Eureka 客户端，通常指的是微服务系统中各个微服务，主要用于和 Eureka Server 进行交互。在微服务应用启动后，Eureka Client 会向 Eureka Server 发送心跳（默认周期为 30 秒）。若 Eureka Server 在多个心跳周期内没有接收到某个 Eureka Client 的心跳，Eureka Server 将它从可用服务列表中移除（默认 90 秒）。

注：“心跳”指的是一段定时发送的自定义信息，让对方知道自己“存活”，以确保连接的有效性。大部分 CS 架构的应用程序都采用了心跳机制，服务端和客户端都可以发心跳。通常情况下是客户端向服务器端发送心跳包，服务端用于判断客户端是否在线。

Eureka 服务注册与发现

Eureka 实现服务注册与发现的原理，如下图所示。

图1：Eureka 原理图

上图中共涉及到以下 3 个角色：

• 服务注册中心（Register Service）：它是一个 Eureka Server，用于提供服务注册和发现功能。
• 服务提供者（Provider Service）：它是一个 Eureka Client，用于提供服务。它将自己提供的服务注册到服务注册中心，以供服务消费者发现。
• 服务消费者（Consumer Service）：它是一个 Eureka Client，用于消费服务。它可以从服务注册中心获取服务列表，调用所需的服务。

Eureka 实现服务注册与发现的流程如下：

1. 搭建一个 Eureka Server 作为服务注册中心；
2. 服务提供者 Eureka Client 启动时，会把当前服务器的信息以服务名（spring.application.name）的方式注册到服务注册中心；
3. 服务消费者 Eureka Client 启动时，也会向服务注册中心注册；
4. 服务消费者还会获取一份可用服务列表，该列表中包含了所有注册到服务注册中心的服务信息（包括服务提供者和自身的信息）；
5. 在获得了可用服务列表后，服务消费者通过 HTTP 或消息中间件远程调用服务提供者提供的服务。

服务注册中心（Eureka Server）所扮演的角色十分重要，它是服务提供者和服务消费者之间的桥梁。服务提供者只有将自己的服务注册到服务注册中心才可能被服务消费者调用，而服务消费者也只有通过服务注册中心获取可用服务列表后，才能调用所需的服务。

Ribbon：Spring Cloud负载均衡与服务调用组件（非常详细）

Spring Cloud Ribbon 是一套基于 Netflix Ribbon 实现的客户端负载均衡和服务调用工具。

Netflix Ribbon 是 Netflix 公司发布的开源组件，其主要功能是提供客户端的负载均衡算法和服务调用。Spring Cloud 将其与 Netflix 中的其他开源服务组件（例如 Eureka、Feign 以及 Hystrix 等）一起整合进 Spring Cloud Netflix 模块中，整合后全称为 Spring Cloud Netflix Ribbon。

Ribbon 是 Spring Cloud Netflix 模块的子模块，它是 Spring Cloud 对 Netflix Ribbon 的二次封装。通过它，我们可以将面向服务的 REST 模板（RestTemplate）请求转换为客户端负载均衡的服务调用。

Ribbon 是 Spring Cloud 体系中最核心、最重要的组件之一。它虽然只是一个工具类型的框架，并不像 Eureka Server（服务注册中心）那样需要独立部署，但它几乎存在于每一个使用 Spring Cloud 构建的微服务中。

Spring Cloud 微服务之间的调用，API 网关的请求转发等内容，实际上都是通过 Spring Cloud Ribbon 来实现的，包括后续我们要介绍的 OpenFeign 也是基于它实现的。

负载均衡

在任何一个系统中，负载均衡都是一个十分重要且不得不去实施的内容，它是系统处理高并发、缓解网络压力和服务端扩容的重要手段之一。

负载均衡（Load Balance） ，简单点说就是将用户的请求平摊分配到多个服务器上运行，以达到扩展服务器带宽、增强数据处理能力、增加吞吐量、提高网络的可用性和灵活性的目的。

常见的负载均衡方式有两种：

• 服务端负载均衡
• 客户端负载均衡

服务端负载均衡

服务端负载均衡是最常见的负载均衡方式，其工作原理如下图。

图1：服务端负载均衡工作原理

服务端负载均衡是在客户端和服务端之间建立一个独立的负载均衡服务器，该服务器既可以是硬件设备（例如 F5），也可以是软件（例如 Nginx）。这个负载均衡服务器维护了一份可用服务端清单，然后通过心跳机制来删除故障的服务端节点，以保证清单中的所有服务节点都是可以正常访问的。

当客户端发送请求时，该请求不会直接发送到服务端进行处理，而是全部交给负载均衡服务器，由负载均衡服务器按照某种算法（例如轮询、随机等），从其维护的可用服务清单中选择一个服务端，然后进行转发。

服务端负载均衡具有以下特点：

• 需要建立一个独立的负载均衡服务器。
• 负载均衡是在客户端发送请求后进行的，因此客户端并不知道到底是哪个服务端提供的服务。
• 可用服务端清单存储在负载均衡服务器上。

客户端负载均衡

相较于服务端负载均衡，客户端服务在均衡则是一个比较小众的概念。

客户端负载均衡的工作原理如下图。

图2：客户端负载均衡工作原理

客户端负载均衡是将负载均衡逻辑以代码的形式封装到客户端上，即负载均衡器位于客户端。客户端通过服务注册中心（例如 Eureka Server）获取到一份服务端提供的可用服务清单。有了服务清单后，负载均衡器会在客户端发送请求前通过负载均衡算法选择一个服务端实例再进行访问，以达到负载均衡的目的；

客户端负载均衡也需要心跳机制去维护服务端清单的有效性，这个过程需要配合服务注册中心一起完成。

客户端负载均衡具有以下特点：

• 负载均衡器位于客户端，不需要单独搭建一个负载均衡服务器。
• 负载均衡是在客户端发送请求前进行的，因此客户端清楚地知道是哪个服务端提供的服务。
• 客户端都维护了一份可用服务清单，而这份清单都是从服务注册中心获取的。

Ribbon 就是一个基于 HTTP 和 TCP 的客户端负载均衡器，当我们将 Ribbon 和 Eureka 一起使用时，Ribbon 会从 Eureka Server（服务注册中心）中获取服务端列表，然后通过负载均衡策略将请求分摊给多个服务提供者，从而达到负载均衡的目的。

服务端负载均衡 VS 客户端负载均衡

下面我们就来对比下，服务端负载均衡和客户端负载均衡到底有什么区别，如下表。

不同点	服务端负载均衡	客户端负载均衡
是否需要建立负载均衡服务器	需要在客户端和服务端之间建立一个独立的负载均衡服务器。	将负载均衡的逻辑以代码的形式封装到客户端上，因此不需要单独建立负载均衡服务器。
是否需要服务注册中心	不需要服务注册中心。	需要服务注册中心。 在客户端负载均衡中，所有的客户端和服务端都需要将其提供的服务注册到服务注册中心上。
可用服务清单存储的位置	可用服务清单存储在位于客户端与服务器之间的负载均衡服务器上。	所有的客户端都维护了一份可用服务清单，这些清单都是从服务注册中心获取的。
负载均衡的时机	先将请求发送到负载均衡服务器，然后由负载均衡服务器通过负载均衡算法，在多个服务端之间选择一个进行访问；即在服务器端再进行负载均衡算法分配。 简单点说就是，先发送请求，再进行负载均衡。	在发送请求前，由位于客户端的服务负载均衡器（例如 Ribbon）通过负载均衡算法选择一个服务器，然后进行访问。 简单点说就是，先进行负载均衡，再发送请求。
客户端是否了解服务提供方信息	由于负载均衡是在客户端发送请求后进行的，因此客户端并不知道到底是哪个服务端提供的服务。	负载均衡是在客户端发送请求前进行的，因此客户端清楚的知道是哪个服务端提供的服务。

OpenFeign：Spring Cloud声明式服务调用组件（非常详细）

Netflix Feign 是 Netflix 公司发布的一种实现负载均衡和服务调用的开源组件。Spring Cloud 将其与 Netflix 中的其他开源服务组件（例如 Eureka、Ribbon 以及 Hystrix 等）一起整合进 Spring Cloud Netflix 模块中，整合后全称为 Spring Cloud Netflix Feign。

Feign 对 Ribbon 进行了集成，利用 Ribbon 维护了一份可用服务清单，并通过 Ribbon 实现了客户端的负载均衡。

Feign 是一种声明式服务调用组件，它在 RestTemplate 的基础上做了进一步的封装。通过 Feign，我们只需要声明一个接口并通过注解进行简单的配置（类似于 Dao 接口上面的 Mapper 注解一样）即可实现对 HTTP 接口的绑定。

通过 Feign，我们可以像调用本地方法一样来调用远程服务，而完全感觉不到这是在进行远程调用。

Feign 支持多种注解，例如 Feign 自带的注解以及 JAX-RS 注解等，但遗憾的是 Feign 本身并不支持 Spring MVC 注解，这无疑会给广大 Spring 用户带来不便。

2019 年 Netflix 公司宣布 Feign 组件正式进入停更维护状态，于是 Spring 官方便推出了一个名为 OpenFeign 的组件作为 Feign 的替代方案。

OpenFeign

OpenFeign 全称 Spring Cloud OpenFeign，它是 Spring 官方推出的一种声明式服务调用与负载均衡组件，它的出现就是为了替代进入停更维护状态的 Feign。

OpenFeign 是 Spring Cloud 对 Feign 的二次封装，它具有 Feign 的所有功能，并在 Feign 的基础上增加了对 Spring MVC 注解的支持，例如 @RequestMapping、@GetMapping 和 @PostMapping 等。

OpenFeign 常用注解

使用 OpenFegin 进行远程服务调用时，常用注解如下表。

注解	说明
@FeignClient	该注解用于通知 OpenFeign 组件对 @RequestMapping 注解下的接口进行解析，并通过动态代理的方式产生实现类，实现负载均衡和服务调用。
@EnableFeignClients	该注解用于开启 OpenFeign 功能，当 Spring Cloud 应用启动时，OpenFeign 会扫描标有 @FeignClient 注解的接口，生成代理并注册到 Spring 容器中。
@RequestMapping	Spring MVC 注解，在 Spring MVC 中使用该注解映射请求，通过它来指定控制器（Controller）可以处理哪些 URL 请求，相当于 Servlet 中 web.xml 的配置。
@GetMapping	Spring MVC 注解，用来映射 GET 请求，它是一个组合注解，相当于 @RequestMapping(method = RequestMethod.GET) 。
@PostMapping	Spring MVC 注解，用来映射 POST 请求，它是一个组合注解，相当于 @RequestMapping(method = RequestMethod.POST) 。

Spring Cloud Finchley 及以上版本一般使用 OpenFeign 作为其服务调用组件。由于 OpenFeign 是在 2019 年 Feign 停更进入维护后推出的，因此大多数 2019 年及以后的新项目使用的都是 OpenFeign，而 2018 年以前的项目一般使用 Feign。

Feign VS OpenFeign

下面我们就来对比下 Feign 和 OpenFeign 的异同。

相同点

Feign 和 OpenFegin 具有以下相同点：

• Feign 和 OpenFeign 都是 Spring Cloud 下的远程调用和负载均衡组件。
• Feign 和 OpenFeign 作用一样，都可以实现服务的远程调用和负载均衡。
• Feign 和 OpenFeign 都对 Ribbon 进行了集成，都利用 Ribbon 维护了可用服务清单，并通过 Ribbon 实现了客户端的负载均衡。
• Feign 和 OpenFeign 都是在服务消费者（客户端）定义服务绑定接口并通过注解的方式进行配置，以实现远程服务的调用。

不同点

Feign 和 OpenFeign 具有以下不同：

• Feign 和 OpenFeign 的依赖项不同，Feign 的依赖为 spring-cloud-starter-feign，而 OpenFeign 的依赖为 spring-cloud-starter-openfeign。
• Feign 和 OpenFeign 支持的注解不同，Feign 支持 Feign 注解和 JAX-RS 注解，但不支持 Spring MVC 注解；OpenFeign 除了支持 Feign 注解和 JAX-RS 注解外，还支持 Spring MVC 注解。

Hystrix：Spring Cloud服务熔断与降级组件（非常详细）

在微服务架构中，一个应用往往由多个服务组成，这些服务之间相互依赖，依赖关系错综复杂。

例如一个微服务系统中存在 A、B、C、D、E、F 等多个服务，它们的依赖关系如下图。

图1：服务依赖关系

通常情况下，一个用户请求往往需要多个服务配合才能完成。如图 1 所示，在所有服务都处于可用状态时，请求 1 需要调用 A、D、E、F 四个服务才能完成，请求 2 需要调用 B、E、D 三个服务才能完成，请求 3 需要调用服务 C、F、E、D 四个服务才能完成。

当服务 E 发生故障或网络延迟时，会出现以下情况：

1. 即使其他所有服务都可用，由于服务 E 的不可用，那么用户请求 1、2、3 都会处于阻塞状态，等待服务 E 的响应。在高并发的场景下，会导致整个服务器的线程资源在短时间内迅速消耗殆尽。
2. 所有依赖于服务 E 的其他服务，例如服务 B、D 以及 F 也都会处于线程阻塞状态，等待服务 E 的响应，导致这些服务的不可用。
3. 所有依赖服务B、D 和 F 的服务，例如服务 A 和服务 C 也会处于线程阻塞状态，以等待服务 D 和服务 F 的响应，导致服务 A 和服务 C 也不可用。

从以上过程可以看出，当微服务系统的一个服务出现故障时，故障会沿着服务的调用链路在系统中疯狂蔓延，最终导致整个微服务系统的瘫痪，这就是“雪崩效应”。为了防止此类事件的发生，微服务架构引入了“熔断器”的一系列服务容错和保护机制。

熔断器

熔断器（Circuit Breaker）一词来源物理学中的电路知识，它的作用是当线路出现故障时，迅速切断电源以保护电路的安全。

在微服务领域，熔断器最早是由 Martin Fowler 在他发表的 《Circuit Breaker》一文中提出。与物理学中的熔断器作用相似，微服务架构中的熔断器能够在某个服务发生故障后，向服务调用方返回一个符合预期的、可处理的降级响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常。这样就保证了服务调用方的线程不会被长时间、不必要地占用，避免故障在微服务系统中的蔓延，防止系统雪崩效应的发生。

Spring Cloud Hystrix

Spring Cloud Hystrix 是一款优秀的服务容错与保护组件，也是 Spring Cloud 中最重要的组件之一。

Spring Cloud Hystrix 是基于 Netflix 公司的开源组件 Hystrix 实现的，它提供了熔断器功能，能够有效地阻止分布式微服务系统中出现联动故障，以提高微服务系统的弹性。Spring Cloud Hystrix 具有服务降级、服务熔断、线程隔离、请求缓存、请求合并以及实时故障监控等强大功能。

Hystrix [hɪst’rɪks]，中文含义是豪猪，豪猪的背上长满了棘刺，使它拥有了强大的自我保护能力。而 Spring Cloud Hystrix 作为一个服务容错与保护组件，也可以让服务拥有自我保护的能力，因此也有人将其戏称为“豪猪哥”。

在微服务系统中，Hystrix 能够帮助我们实现以下目标：

• 保护线程资源：防止单个服务的故障耗尽系统中的所有线程资源。
• 快速失败机制：当某个服务发生了故障，不让服务调用方一直等待，而是直接返回请求失败。
• 提供降级（FallBack）方案：在请求失败后，提供一个设计好的降级方案，通常是一个兜底方法，当请求失败后即调用该方法。
• 防止故障扩散：使用熔断机制，防止故障扩散到其他服务。
• 监控功能：提供熔断器故障监控组件 Hystrix Dashboard，随时监控熔断器的状态。

Hystrix 服务降级

Hystrix 提供了服务降级功能，能够保证当前服务不受其他服务故障的影响，提高服务的健壮性。

服务降级的使用场景有以下 2 种：

• 在服务器压力剧增时，根据实际业务情况及流量，对一些不重要、不紧急的服务进行有策略地不处理或简单处理，从而释放服务器资源以保证核心服务正常运作。
• 当某些服务不可用时，为了避免长时间等待造成服务卡顿或雪崩效应，而主动执行备用的降级逻辑立刻返回一个友好的提示，以保障主体业务不受影响。

我们可以通过重写 HystrixCommand 的 getFallBack() 方法或 HystrixObservableCommand 的 resumeWithFallback() 方法，使服务支持服务降级。

Hystrix 服务降级 FallBack 既可以放在服务端进行，也可以放在客户端进行。

Hystrix 会在以下场景下进行服务降级处理：

• 程序运行异常
• 服务超时
• 熔断器处于打开状态
• 线程池资源耗尽

Gateway：Spring Cloud API网关组件（非常详细）

在微服务架构中，一个系统往往由多个微服务组成，而这些服务可能部署在不同机房、不同地区、不同域名下。这种情况下，客户端（例如浏览器、手机、软件工具等）想要直接请求这些服务，就需要知道它们具体的地址信息，例如 IP 地址、端口号等。

这种客户端直接请求服务的方式存在以下问题：

• 当服务数量众多时，客户端需要维护大量的服务地址，这对于客户端来说，是非常繁琐复杂的。
• 在某些场景下可能会存在跨域请求的问题。
• 身份认证的难度大，每个微服务需要独立认证。

我们可以通过 API 网关来解决这些问题，下面就让我们来看看什么是 API 网关。

API 网关

API 网关是一个搭建在客户端和微服务之间的服务，我们可以在 API 网关中处理一些非业务功能的逻辑，例如权限验证、监控、缓存、请求路由等。

API 网关就像整个微服务系统的门面一样，是系统对外的唯一入口。有了它，客户端会先将请求发送到 API 网关，然后由 API 网关根据请求的标识信息将请求转发到微服务实例。

图1：两种服务访问方式对比

对于服务数量众多、复杂度较高、规模比较大的系统来说，使用 API 网关具有以下好处：

• 客户端通过 API 网关与微服务交互时，客户端只需要知道 API 网关地址即可，而不需要维护大量的服务地址，简化了客户端的开发。
• 客户端直接与 API 网关通信，能够减少客户端与各个服务的交互次数。
• 客户端与后端的服务耦合度降低。
• 节省流量，提高性能，提升用户体验。
• API 网关还提供了安全、流控、过滤、缓存、计费以及监控等 API 管理功能。

常见的 API 网关实现方案主要有以下 5 种：

• Spring Cloud Gateway
• Spring Cloud Netflix Zuul
• Kong
• Nginx+Lua
• Traefik

本节，我们就对 Spring Cloud Gateway 进行详细介绍。

Spring Cloud Gateway

Spring Cloud Gateway 是 Spring Cloud 团队基于 Spring 5.0、Spring Boot 2.0 和 Project Reactor 等技术开发的高性能 API 网关组件。

Spring Cloud Gateway 旨在提供一种简单而有效的途径来发送 API，并为它们提供横切关注点，例如：安全性，监控/指标和弹性。

Spring Cloud Gateway 是基于 WebFlux 框架实现的，而 WebFlux 框架底层则使用了高性能的 Reactor 模式通信框架 Netty。

Spring Cloud Gateway 核心概念

Spring Cloud GateWay 最主要的功能就是路由转发，而在定义转发规则时主要涉及了以下三个核心概念，如下表。

核心概念	描述
Route（路由）	网关最基本的模块。它由一个 ID、一个目标 URI、一组断言（Predicate）和一组过滤器（Filter）组成。
Predicate（断言）	路由转发的判断条件，我们可以通过 Predicate 对 HTTP 请求进行匹配，例如请求方式、请求路径、请求头、参数等，如果请求与断言匹配成功，则将请求转发到相应的服务。
Filter（过滤器）	过滤器，我们可以使用它对请求进行拦截和修改，还可以使用它对上文的响应进行再处理。

注意：其中 Route 和 Predicate 必须同时声明。

Spring Cloud Gateway 的特征

Spring Cloud Gateway 具有以下特性：

• 基于 Spring Framework 5、Project Reactor 和 Spring Boot 2.0 构建。
• 能够在任意请求属性上匹配路由。
• predicates（断言） 和 filters（过滤器）是特定于路由的。
• 集成了 Hystrix 熔断器。
• 集成了 Spring Cloud DiscoveryClient（服务发现客户端）。
• 易于编写断言和过滤器。
• 能够限制请求频率。
• 能够重写请求路径。

Gateway 的工作流程

Spring Cloud Gateway 工作流程如下图。

图2：Spring Cloud Gateway 工作流程

Spring Cloud Gateway 工作流程说明如下：

1. 客户端将请求发送到 Spring Cloud Gateway 上。
2. Spring Cloud Gateway 通过 Gateway Handler Mapping 找到与请求相匹配的路由，将其发送给 Gateway Web Handler。
3. Gateway Web Handler 通过指定的过滤器链（Filter Chain），将请求转发到实际的服务节点中，执行业务逻辑返回响应结果。
4. 过滤器之间用虚线分开是因为过滤器可能会在转发请求之前（pre）或之后（post）执行业务逻辑。
5. 过滤器（Filter）可以在请求被转发到服务端前，对请求进行拦截和修改，例如参数校验、权限校验、流量监控、日志输出以及协议转换等。
6. 过滤器可以在响应返回客户端之前，对响应进行拦截和再处理，例如修改响应内容或响应头、日志输出、流量监控等。
7. 响应原路返回给客户端。

总而言之，客户端发送到 Spring Cloud Gateway 的请求需要通过一定的匹配条件，才能定位到真正的服务节点。在将请求转发到服务进行处理的过程前后（pre 和 post），我们还可以对请求和响应进行一些精细化控制。

Predicate 就是路由的匹配条件，而 Filter 就是对请求和响应进行精细化控制的工具。有了这两个元素，再加上目标 URI，就可以实现一个具体的路由了。

Predicate 断言

Spring Cloud Gateway 通过 Predicate 断言来实现 Route 路由的匹配规则。简单点说，Predicate 是路由转发的判断条件，请求只有满足了 Predicate 的条件，才会被转发到指定的服务上进行处理。

使用 Predicate 断言需要注意以下 3 点：

• Route 路由与 Predicate 断言的对应关系为“一对多”，一个路由可以包含多个不同断言。
• 一个请求想要转发到指定的路由上，就必须同时匹配路由上的所有断言。
• 当一个请求同时满足多个路由的断言条件时，请求只会被首个成功匹配的路由转发。

图3：Predicate 断言匹配

常见的 Predicate 断言如下表（假设转发的 URI 为 http://localhost:8001）。

断言	示例	说明
Path	- Path=/dept/list/**	当请求路径与 /dept/list/** 匹配时，该请求才能被转发到 http://localhost:8001 上。
Before	- Before=2021-10-20T11:47:34.255+08:00[Asia/Shanghai]	在 2021 年 10 月 20 日 11 时 47 分 34.255 秒之前的请求，才会被转发到 http://localhost:8001 上。
After	- After=2021-10-20T11:47:34.255+08:00[Asia/Shanghai]	在 2021 年 10 月 20 日 11 时 47 分 34.255 秒之后的请求，才会被转发到 http://localhost:8001 上。
Between	- Between=2021-10-20T15:18:33.226+08:00[Asia/Shanghai],2021-10-20T15:23:33.226+08:00[Asia/Shanghai]	在 2021 年 10 月 20 日 15 时 18 分 33.226 秒 到 2021 年 10 月 20 日 15 时 23 分 33.226 秒之间的请求，才会被转发到 http://localhost:8001 服务器上。
Cookie	- Cookie=name,c.biancheng.net	携带 Cookie 且 Cookie 的内容为 name=c.biancheng.net 的请求，才会被转发到 http://localhost:8001 上。
Header	- Header=X-Request-Id,\d+	请求头上携带属性 X-Request-Id 且属性值为整数的请求，才会被转发到 http://localhost:8001 上。
Method	- Method=GET	只有 GET 请求才会被转发到 http://localhost:8001 上。

Config：Spring Cloud分布式配置组件（非常详细）

在分布式微服务系统中，几乎所有服务的运行都离不开配置文件的支持，这些配置文件通常由各个服务自行管理，以 properties 或 yml 格式保存在各个微服务的类路径下，例如 application.properties 或 application.yml 等。

这种将配置文件散落在各个服务中的管理方式，存在以下问题：

• 管理难度大：配置文件散落在各个微服务中，难以管理。
• 安全性低：配置跟随源代码保存在代码库中，容易造成配置泄漏。
• 时效性差：微服务中的配置修改后，必须重启服务，否则无法生效。
• 局限性明显：无法支持动态调整，例如日志开关、功能开关。

为了解决这些问题，通常我们都会使用配置中心对配置进行统一管理。市面上开源的配置中心有很多，例如百度的 Disconf、淘宝的 diamond、360 的 QConf、携程的 Apollo 等都是解决这类问题的。Spring Cloud 也有自己的分布式配置中心，那就是 Spring Cloud Config。

Spring Cloud Config

Spring Cloud Config 是由 Spring Cloud 团队开发的项目，它可以为微服务架构中各个微服务提供集中化的外部配置支持。

简单点说就是，Spring Cloud Config 可以将各个微服务的配置文件集中存储在一个外部的存储仓库或系统（例如 Git 、SVN 等）中，对配置的统一管理，以支持各个微服务的运行。

Spring Cloud Config 包含以下两个部分：

• Config Server：也被称为分布式配置中心，它是一个独立运行的微服务应用，用来连接配置仓库并为客户端提供获取配置信息、加密信息和解密信息的访问接口。
• Config Client：指的是微服务架构中的各个微服务，它们通过 Config Server 对配置进行管理，并从 Config Sever 中获取和加载配置信息。

Spring Cloud Config 默认使用 Git 存储配置信息，因此使用 Spirng Cloud Config 构建的配置服务器天然就支持对微服务配置的版本管理。我们可以使用 Git 客户端工具方便地对配置内容进行管理和访问。除了 Git 外，Spring Cloud Config 还提供了对其他存储方式的支持，例如 SVN、本地化文件系统等。

Spring Cloud Config 工作原理

Spring Cloud Config 工作原理如下图。

图1​：Spring Cloud Config 工作原理

Spring Cloud Config 工作流程如下：

1. 开发或运维人员提交配置文件到远程的 Git 仓库。
2. Config 服务端（分布式配置中心）负责连接配置仓库 Git，并对 Config 客户端暴露获取配置的接口。
3. Config 客户端通过 Config 服务端暴露出来的接口，拉取配置仓库中的配置。
4. Config 客户端获取到配置信息，以支持服务的运行。

Spring Cloud Config 的特点

Spring Cloud Config 具有以下特点：

• Spring Cloud Config 由 Spring Cloud 团队开发，可以说是 Spring 的亲儿子，能够与 Spring 的生态体系无缝集成。
• Spring Cloud Config 将所有微服务的配置文件集中存储在一个外部的存储仓库或系统（例如 Git）中，统一管理。
• Spring Cloud Config 配置中心将配置以 REST 接口的形式暴露给各个微服务，以方便各个微服务获取。
• 微服务可以通过 Spring Cloud Config 向配置中心统一拉取属于它们自己的配置信息。
• 当配置发生变化时，微服务不需要重启即可感知到配置的变化，并自动获取和应用最新配置。
• 一个应用可能有多个环境，例如开发（dev）环境、测试（test）环境、生产（prod）环境等等，开发人员可以通过 Spring Cloud Config 对不同环境的各配置进行管理，且能够确保应用在环境迁移后仍然有完整的配置支持其正常运行。

Spring Cloud Alibaba是什么

Spring Cloud 本身并不是一个拿来即可用的框架，它是一套微服务规范，这套规范共有两代实现。

• 第一代实现： Spring Cloud Netflix，
• 第二代实现： Spring Cloud Alibaba。

2018 年 12 月12 日，Netflix 公司宣布 Spring Cloud Netflix 系列大部分组件都进入维护模式，不再添加新特性。这严重地限制了 Spring Cloud 的高速发展，于是各大互联网公司和组织开始把目光转向 Spring Cloud 的第二代实现：Spring Cloud Alibaba。

Spring Cloud Alibaba

Spring Cloud Alibaba 是阿里巴巴结合自身丰富的微服务实践而推出的微服务开发的一站式解决方案，是 Spring Cloud 第二代实现的主要组成部分。

Spring Cloud Alibaba 吸收了 Spring Cloud Netflix 的核心架构思想，并进行了高性能改进。自 Spring Cloud Netflix 进入停更维护后，Spring Cloud Alibaba 逐渐代替它成为主流的微服务框架。

Spring Cloud Alibaba 是国内首个进入 Spring 社区的开源项目。2018 年 7 月，Spring Cloud Alibaba 正式开源，并进入 Spring Cloud 孵化器中孵化；2019 年 7 月，Spring Cloud 官方宣布 Spring Cloud Alibaba 毕业，并将仓库迁移到 Alibaba Github OSS 下。

虽然 Spring Cloud Alibaba 诞生时间不久，但俗话说的好“大树底下好乘凉”，依赖于阿里巴巴强大的技术影响力，Spring Cloud Alibaba 在业界得到了广泛的使用，成功案例也越来越多。

Spring Cloud Alibaba 组件

Spring Cloud Alibaba 包含了多种开发分布式微服务系统的必需组件

• Nacos：阿里巴巴开源产品，一个更易于构建云原生应用的动态服务发现,配置管理和服务管理平台。
• Sentinel：阿里巴巴开源产品，把流量作为切入点,从流量控制,熔断降级,系统负载保护等多个维度保护服务的稳定性。
• RocketMQ：Apache RocketMQ 是一款基于Java 的高性能、高吞吐量的分布式消息和流计算平台。
• Dubbo：Apache Dubbo 是一款高性能的 Java RPC 框架。
• Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
• Alibaba Cloud OSS：阿里云对象存储服务器（Object Storage Service，简称OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。
• Alibaba Cloud Schedulerx：阿里中间件团队开发的一款分布式调度产品,支持周期性的任务与固定时间点触发任务。

通过 Spring Cloud Alibaba 的这些组件，我们只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

Spring Cloud Alibaba 的应用场景

Spring Cloud Alibaba 的应用场景如下：

• 大型复杂的系统，例如大型电商系统。
• 高并发系统，例如大型门户网站、商品秒杀系统。
• 需求不明确，且变更很快的系统，例如创业公司业务系统。

Spring Cloud 两代实现组件对比

下表展示了 Spring Cloud 两代实现的组件对比情况。

Spring Cloud 第一代实现（Netflix）	状态	Spring Cloud 第二代实现（Alibaba）	状态
Ereka	2.0 孵化失败	Nacos Discovery	性能更好，感知力更强
Ribbon	停更进维	Spring Cloud Loadbalancer	Spring Cloud 原生组件，用于代替 Ribbon
Hystrix	停更进维	Sentinel	可视化配置，上手简单
Zuul	停更进维	Spring Cloud Gateway	性能为 Zuul 的 1.6 倍
Spring Cloud Config	搭建过程复杂，约定过多，无可视化界面，上手难点大	Nacos Config	搭建过程简单，有可视化界面，配置管理更简单，容易上手

Spring Cloud Alibaba 版本依赖

Spring Cloud、Spring Cloud Alibaba 以及 Spring Boot 之间版本依赖关系如下。

Spring Cloud 版本	Spring Cloud Alibaba 版本	Spring Boot 版本
Spring Cloud 2020.0.1	2021.1	2.4.2
Spring Cloud Hoxton.SR12	2.2.7.RELEASE	2.3.12.RELEASE
Spring Cloud Hoxton.SR9	2.2.6.RELEASE	2.3.2.RELEASE
Spring Cloud Greenwich.SR6	2.1.4.RELEASE	2.1.13.RELEASE
Spring Cloud Hoxton.SR3	2.2.1.RELEASE	2.2.5.RELEASE
Spring Cloud Hoxton.RELEASE	2.2.0.RELEASE	2.2.X.RELEASE
Spring Cloud Greenwich	2.1.2.RELEASE	2.1.X.RELEASE
Spring Cloud Finchley	2.0.4.RELEASE（停止维护，建议升级）	2.0.X.RELEASE
Spring Cloud Edgware	1.5.1.RELEASE（停止维护，建议升级）	1.5.X.RELEASE

Spring Cloud Alibaba 组件版本关系

Spring Cloud Alibaba 下各组件版本关系如下表。

Spring Cloud Alibaba 版本	Sentinel 版本	Nacos 版本	RocketMQ 版本	Dubbo 版本	Seata 版本
2.2.7.RELEASE	1.8.1	2.0.3	4.6.1	2.7.13	1.3.0
2.2.6.RELEASE	1.8.1	1.4.2	4.4.0	2.7.8	1.3.0
2021.1 or 2.2.5.RELEASE or 2.1.4.RELEASE or 2.0.4.RELEASE	1.8.0	1.4.1	4.4.0	2.7.8	1.3.0
2.2.3.RELEASE or 2.1.3.RELEASE or 2.0.3.RELEASE	1.8.0	1.3.3	4.4.0	2.7.8	1.3.0
2.2.1.RELEASE or 2.1.2.RELEASE or 2.0.2.RELEASE	1.7.1	1.2.1	4.4.0	2.7.6	1.2.0
2.2.0.RELEASE	1.7.1	1.1.4	4.4.0	2.7.4.1	1.0.0
2.1.1.RELEASE or 2.0.1.RELEASE or 1.5.1.RELEASE	1.7.0	1.1.4	4.4.0	2.7.3	0.9.0
2.1.0.RELEASE or 2.0.0.RELEASE or 1.5.0.RELEASE	1.6.3	1.1.1	4.4.0	2.7.3	0.7.1

Nacos：Spring Cloud Alibaba服务注册与配置中心（非常详细）

Nacos 英文全称为 Dynamic Naming and Configuration Service，是一个由阿里巴巴团队使用 Java 语言开发的开源项目。

Nacos 是一个更易于帮助构建云原生应用的动态服务发现、配置和服务管理平台（参考自 Nacos 官网）。

Nacos 的命名是由 3 部分组成：

组成部分	全称	描述
Na	naming/nameServer	即服务注册中心，与 Spring Cloud Eureka 的功能类似。
co	configuration	即配置中心，与 Spring Cloud Config+Spring Cloud Bus 的功能类似。
s	service	即服务，表示 Nacos 实现的服务注册中心和配置中心都是以服务为核心的。

我们可以将 Nacos 理解成服务注册中心和配置中心的组合体，它可以替换 Eureka 作为服务注册中心，实现服务的注册与发现；还可以替换 Spring Cloud Config 作为配置中心，实现配置的动态刷新。

Nacos 作为服务注册中心经历了十年“双十一”的洪峰考验，具有简单易用、稳定可靠、性能卓越等优点，可以帮助用户更敏捷、容易地构建和管理微服务应用。

Nacos 支持几乎所有主流类型“服务”的发现、配置和管理：

Spring全套教学资料

Spring是Java程序员的《葵花宝典》，其中提供的各种大招，能简化我们的开发，大大提升开发效率！目前99%的公司使用了Spring，大家可以去各大招聘网站看一下，Spring算是必备技能，所以一定要掌握。

目录：

部分内容：

Spring源码

• 第一部分 Spring 概述
• 第二部分 核心思想
• 第三部分 手写实现 IoC 和 AOP（自定义Spring框架）
• 第四部分 Spring IOC 高级应用
  基础特性
  高级特性
• 第五部分 Spring IOC源码深度剖析
  设计优雅
  设计模式
  注意：原则、方法和技巧
• 第六部分 Spring AOP 应用
  声明事务控制
• 第七部分 Spring AOP源码深度剖析
  必要的笔记、必要的图、通俗易懂的语言化解知识难点

脚手框架：SpringBoot技术

它的目标是简化Spring应用和服务的创建、开发与部署，简化了配置文件，使用嵌入式web服务器，含有诸多开箱即用的微服务功能，可以和spring cloud联合部署。

Spring Boot的核心思想是约定大于配置，应用只需要很少的配置即可，简化了应用开发模式。

• SpringBoot入门
• 配置文件
• 日志
• Web开发
• Docker
• SpringBoot与数据访问
• 启动配置原理
• 自定义starter

微服务架构：Spring Cloud Alibaba

同 Spring Cloud 一样，Spring Cloud Alibaba 也是一套微服务解决方案，包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

• 微服务架构介绍
• Spring Cloud Alibaba介绍
• 微服务环境搭建
• 服务治理
• 服务容错
• 服务网关
• 链路追踪
• ZipKin集成及数据持久化
• 消息驱动
• 短信服务
• Nacos Confifig—服务配置
• Seata—分布式事务
• Dubbo—rpc通信

Spring MVC

目录：

部分内容：

言化解知识难点

[外链图片转存中…(img-S8lpv3Gg-1714508725910)]

[外链图片转存中…(img-MoCNxNsq-1714508725911)]

脚手框架：SpringBoot技术

它的目标是简化Spring应用和服务的创建、开发与部署，简化了配置文件，使用嵌入式web服务器，含有诸多开箱即用的微服务功能，可以和spring cloud联合部署。

Spring Boot的核心思想是约定大于配置，应用只需要很少的配置即可，简化了应用开发模式。

• SpringBoot入门
• 配置文件
• 日志
• Web开发
• Docker
• SpringBoot与数据访问
• 启动配置原理
• 自定义starter

[外链图片转存中…(img-xVatCXHK-1714508725911)]

[外链图片转存中…(img-GW8rHibg-1714508725911)]

微服务架构：Spring Cloud Alibaba

同 Spring Cloud 一样，Spring Cloud Alibaba 也是一套微服务解决方案，包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

• 微服务架构介绍
• Spring Cloud Alibaba介绍
• 微服务环境搭建
• 服务治理
• 服务容错
• 服务网关
• 链路追踪
• ZipKin集成及数据持久化
• 消息驱动
• 短信服务
• Nacos Confifig—服务配置
• Seata—分布式事务
• Dubbo—rpc通信

[外链图片转存中…(img-B3EpY3CJ-1714508725911)]

[外链图片转存中…(img-FYaNUf2g-1714508725912)]

Spring MVC

目录：

[外链图片转存中…(img-BJaQqfuT-1714508725912)]

[外链图片转存中…(img-toxwVM2R-1714508725912)]

[外链图片转存中…(img-Yr3M64lb-1714508725913)]

部分内容：

[外链图片转存中…(img-qiq6Tatv-1714508725913)]

[外链图片转存中…(img-puE1vh3g-1714508725913)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录