代码地址：https://gitee.com/gaibianzlp/springcould-alibaba-example.git
学习视频地址：https://www.bilibili.com/video/BV1JP4y1b7L5?p=63&spm_id_from=pageDriver
https://blog.csdn.net/m0_45234510/article/details/116676530

微服务介绍

概述

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

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

此外，阿里云同时还提供了 Spring Cloud Alibaba 企业版 微服务解决方案，包括无侵入服务治理(全链路灰度，无损上下线，离群实例摘除等)，企业级 Nacos 注册配置中心和企业级云原生网关等众多产品。

微服务演变过程

随着互联网的发展，网站应用的规模也在不断的扩大，进而导致系统架构也在不断的进行变化。从互联网早起到现在，系统架构大体经历了下面几个过程:
单体应用架构—>垂直应用架构—>分布式架构—>SOA架构—>微服务架构，当然还有悄然兴起Service Mesh(服务网格化)。接下来我们就来了解一下每种系统架构是什么样子的， 以及各有什么优缺点。

单体应用架构

互联网早期，一般的网站应用流量较小，只需一个应用，将所有功能代码都部署在一起就可以，这样可以减少开发、部署和维护的成本。比如说一个电商系统，里面会包含很多用户管理，商品管理，订单管理，物流管理等等很多模块，我们会把它们做成一个web项目，然后部署到一台tomcat服务器上。

优点：

• 项目架构简单，小型项目的话， 开发成本低
• 项目部署在一个节点上， 维护方便

缺点：

• 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护
• 项目模块之间紧密耦合，单点容错率低
• 无法针对不同模块进行针对性优化和水平扩展

垂直应用架构

随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会有比较大的访问量.
还是以上面的电商为例子， 用户访问量的增加可能影响的只是用户和订单模块， 但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块， 而不增加消息模块. 此时单体应用就做不到了， 垂直应用就应运而生了.

所谓的垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率。比如我们可以将上面电商的单体应用拆分成:

• 电商系统(用户管理 商品管理 订单管理)
• 后台系统(用户管理 订单管理 客户管理)
• CMS系统(广告管理 营销管理)

这样拆分完毕之后，一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台和CMS的节点。
优点：

• 系统拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水扩展
• 一个系统的问题不会影响到其他系统，提高容错率

缺点：

• 系统之间相互独立， 无法进行相互调用
• 系统之间相互独立， 会有重复的开发任务

分布式架构

当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？
这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

优点：

• 抽取公共的功能为服务层，提高代码复用性

缺点：

• 系统间耦合度变高，调用关系错综复杂，难以维护

  SOA架构

  在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加
  一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOA Service Oriented
  Architecture)是关键。
  
  优点:

• 使用治理中心（ESB\dubbo）解决了服务间调用关系的自动调节

缺点:

• 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )
• 服务关系复杂，运维、测试部署困难

微服务架构

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的”彻底拆分”。

微服务架构与SOA架构的不同

微服务架构比 SOA架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级。

SOA 架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。项目体现特征微服务架构比 SOA 架构更加适合与互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。
优点：

• 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展
• 微服务之间采用Restful等轻量级http协议相互调用

缺点：

• 分布式系统开发的技术成本高（容错、分布式事务等）
• 复杂性更高。各个微服务进行分布式独立部署，当进行模块调用的时候，分布式将会变得更加麻烦。

微服务架构介绍

①：英文:https://martinfowler.com/articles/microservices.html
②: 中文:http://blog.cuicc.com/blog/2015/07/22/microservices
微服务其实是一种架构风格 ，我们在开发一个应用的时候这个应用应该是由一组小型服务组成，每个小型服务都运行在自己的进程内；小服务之间通过HTTP的方式进行互联互通。

微服务架构的常见问题

一旦采用微服务系统架构，就势必会遇到这样几个问题：

• 这么多小服务，如何管理他们？(服务治理 注册中心[服务注册 发现 剔除]) nacos
• 这么多小服务，他们之间如何通讯？(restful rpc dubbo feign) httpclient(“url”,参数)， springBootrestTemplate(“url”,参数) ,, feign
• 这么多小服务，客户端怎么访问他们？(网关) gateway
• 这么多小服务，一旦出现问题了，应该如何自处理？(容错) sentinel
• 这么多小服务，一旦出现问题了，应该如何排错? (链路追踪) skywalking

4个9 52.6分钟 5个9 5分钟
对于上面的问题，是任何一个微服务设计者都不能绕过去的，因此大部分的微服务产品都针对每一
个问题提供了相应的组件来解决它们。

常见微服务架构

dubbo: zookeeper +dubbo + SpringMVC/SpringBoot

• 配套 通信方式：rpc
• 注册中心：zookeeper / redis
• 配置中心：diamond

SpringCloud：全家桶+轻松嵌入第三方组件(Netflix)

• 配套 通信方式：http restful
• 注册中心：eruka / consul
• 配置中心：config
• 断 路 器：hystrix
• 网关：zuul
• 分布式追踪系统：sleuth + zipkin

  SpringCloud Alibaba

  Spring Cloud 以微服务为核心的分布式系统构建标准
  “分布式系统中的常见模式”给了 Spring Cloud 一个清晰的定位，即“模式”。也就是说 Spring Cloud 是针对分布式系统开发所做的通用抽象，
  是标准模式的实现。这个定义非常抽象，看完之后并不能知道 Spring Cloud 具体包含什么内容。再来看一下 Spring 官方给出的一个 High Light 的
  架构图，就可以对这套模式有更清晰的认识：
  可以看到这个图中间就是各个 Microservice，也就是我们的这个微服务的实现，周边周围的话就是去围绕这个微服务来去做各种辅助的信息事情。
  例如分布式追踪、服务注册、配置服务等，都绕微服务运行时所依赖的必不可少的的支持性功能。我们可以得出这样一个结论：Spring Cloud 是以微服务为核心的分布式系统的一个构建标准。

Spring Cloud Alibaba 介绍

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发微服务架构的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发微服务架构。

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

根据 Jakarta 2019 年的调研报告，Spring Boot 拥有非常高的占比。熟悉 Java 语言的同学，应该对 Spring 框架都不会陌生。其倡导的依赖倒置、
面向切面编程等特性已经形成了 Java 语言的事实标准，几乎所有三方框架都会提供对 Spring 框架的支持。

Spring Cloud Alibaba 的定位

既然说 Spring Cloud 是标准，那么自然少不了针对标准的实现。这里，为大家介绍下 Spring Cloud Alibaba 这套实现。先给出下面这张图帮助大
家理解 Spring Cloud Alibaba 的定位：

这里给大家这么一个公式，这个叫做：“3 加 2”。

3 指的就是图中深色的部分，其实它就是 Spring Cloud 标准，一共有 3 层。中间颜色最深的部分就是及整个微服务最核心的内容，包括了“ RPC调用”以及“服务注册与发现”。第二层，也就是围绕着核心的这一圈，是一些辅助微服务更好的工作功能，包括了负载均衡、路由、网关、断路器，还有就是追踪等等这些内容。再外层的话，主要是一些分布式云环境里通用能力。

“3 加 2”中的“2”，指的就是上图中最外面这一圈。这一部分就是这个我们 Spring Cloud Alibaba 的一个定义，它其实包含两个部分的内容：右上部分是对于 Spring Cloud 标准的实现。例如，我们通过 Dubbo 实现了 RPC 调用功能，通过 Nacos 实现了“服务注册与发现”、“分布式配置”，通过 Sentinel 实现了断路器等等，这里就不一一列举了。

左下部分是我们 Spring Cloud Alibaba 对阿里云各种服务的集成。可能很多同学会有这样的一个问题：为什么要加上这一部分呢？此时回头审视一下 Spring Cloud ，它仅仅是一个微服务的一个框架。但是在实际生产过程中，单独使用微服务框架其实并不足以支撑我们去构建一个完整的系统。所以这部分是用阿里帮助开发者完成微服务以外的云产品集成的功能。

这里可能会很多同学会有这么一个担心：是不是使用了 Spring Cloud Alibaba，就会被阿里云平台绑定呢？在此，我们明确的告诉大家，这是不会的。为什么这么说呢？如上面说的，“3 加 2”中的 2 是被分为两个部分的。其中对 Spring Cloud 的实现是完全独立的，开发者可以只是用这部分实现运行在任何云平台中。当然，另一部分，由于天然是对阿里云服务的集成，这部分是和平台相关的。这里给开发者充分的自由，选择只是用其中
的部分还是全部产品。当然，我们也非常欢迎开发者选择使用阿里云的全套服务，我们也会尽量保证使用整套产品时的连贯性与开发的便利性。

Spring Cloud 各套实现对比

Spring Cloud 作为一套标准，它的实现肯定不止一套，那么各套实现都有什么区别呢？我们来一起看一下下面这张图：

可以发现 Spring Cloud Alibaba 是所有的实现方案中功能最齐全的。尤其是在 Netflix 停止更新了以后，Spring Cloud Alibaba 依然在持续更新和迭代。
图
从 18 年 7 月份 Spring Cloud Alibaba 正式提交代码开始，就得到了大家广泛的关注。截止今天，Spring Cloud Alibaba 一共获得了超过了 1.5 万
的 star 数，已经的领先于所有其他实现的总和。
根据今年 X-lab 开放实验室刚刚发布的《2020 年微服务领域开源数字化报告》，Spring Cloud Alibaba 已经成为最活跃的 Spring Cloud 实现。

Spring Cloud Alibaba 生态

可以看到除了围绕着 Spring Cloud 的标准实现以外，还有包括的数据、资源、消息、缓存等各种类型的服务。在不同类型的服务下，也有很多具体
的产品可供用户选择。

Spring Cloud Alibaba 用户数

截止到今天，Spring Cloud Alibaba 获得了数超过 1.5w 的 star 数。同时在 Github 上的项目依赖，就是对 Spring Cloud Alibaba 产生依赖关系的产品，也超过了 6000。最重要的，使用 Spring Cloud Alibaba 的公司超过 1000 家。当然不只是外部的公司在使用，阿里内部也在使用。经过了
双十一的洗礼，其实整个这套框架它的这个稳定性可靠性都得到了印证。

Spring Cloud Alibaba环境搭建

SpringCloud Alibaba 依赖 Java 环境来运行。还需要为此配置 Maven环境，请确保是在以下版本环境中安装使用:

• 64 bit JDK 1.8+；下载 & 配置。 1.8.0_131
• Maven 3.2.x+；下载 & 配置。 3.6.1

1. 基于SpringBoot的父maven项目
   2. 创建2个服务（订单服务和库存服务）

版本说明：https://github.com/alibaba/spring-cloud-alibaba/wiki/%E7%89%88%E6%9C%AC%E8%AF%B4%E6%98%8E

• Spring Cloud Alibaba:2.2.5.RELEASE
• Spring Boot :2.3.2.RELEASE

• Spring Cloud:Hoxton.SR8

  
  最新的版本选择： Spring Cloud Alibaba 2.2.5.RELEASE

Java 工程脚手架：更适合亚太区 Java 开发者的脚手架

很多开发者应该跟我一样，都有过这样的经历：创建新应用时，先找一个我们最熟悉的一个老应用，把它里边的业务代码全部清理干净。然后相关的各种配置名称全部改掉，最终做出一个空的一个应用模板。再把这个应用模板拿过来改个名子，就变成了一个新的应用。

当然可能有的同学会做的更多一些，例如长期维护这么一个空白模板在那里。下次拿过出来之后再改改个名字，就是一个新的应用。这样做可能是一个相对保险的方案，
但是缺点也非常明显：

• 版本老旧，新特性无法享受
• 团队知识无法沉淀
• 重复劳动

通过提供 Java 工程脚手架来解决这个问题。下面就是 Java 工程脚手架的页面：https://start.aliyun.com/bootstrap.html
在这里，开发者设置项目的基本信息，例如：开发语言、Java 版本、Spring Boot 版本等内容。

Nacos

nacos 官方文档地址：https://nacos.io/zh-cn/docs/what-is-nacos.html

什么是 Nacos

概览

欢迎来到 Nacos 的世界！

Nacos 致力于帮助您服务发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。

Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

什么是 Nacos？

Nacos 的关键特性包括:

• 服务发现和服务健康监测 Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用 原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。 对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。

• 动态配置服务 动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。Nacos 提供了一个简洁易用的UI (控制台样例 Demo) 帮助您管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。

• 动态 DNS 服务 动态 DNS 服务支持权重路由，让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。Nacos 提供了一些简单的 DNS APIs TODO 帮助您管理服务的关联域名和可用的 IP:PORT 列表.

• 服务及其元数据管理Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。
• 更多的特性列表 …

Nacos 地图

一图看懂 Nacos，下面架构部分会详细介绍

• 特性大图：要从功能特性，非功能特性，全面介绍我们要解的问题域的特性诉求
• 架构大图：通过清晰架构，让您快速进入 Nacos 世界
• 业务大图：利用当前特性可以支持的业务场景，及其最佳实践
• 生态大图：系统梳理 Nacos 和主流技术生态的关系
• 优势大图：展示 Nacos 核心竞争力
• 战略大图：要从战略到战术层面讲 Nacos 的宏观优势

核心功能

服务注册：Nacos Client会通过发送REST请求的方式向Nacos Server注册自己的服务，提供自身的元数据，比如ip地址、端口等信息。Nacos Server接收到注册请求后，就会把这些元数据信息存储在一个双层的内存Map中。
服务心跳：在服务注册后，Nacos Client会维护一个定时心跳来持续通知Nacos Server，说明服务一直处于可用状态，防止被剔除。默认5s发送一次心跳。

服务同步：Nacos Server集群之间会互相同步服务实例，用来保证服务信息的一致性。 leader raft 服务发现：服务消费者（Nacos Client）在调用服务提供者的服务时，会发送一个REST请求给Nacos Server，获取上面
注册的服务清单，并且缓存在Nacos Client本地，同时会在Nacos Client本地开启一个定时任务定时拉取服务端最新的注册表信息更新到本地缓存

服务健康检查：Nacos Server会开启一个定时任务用来检查注册服务实例的健康情况，对于超过15s没有收到客户端心跳的实例会将它的healthy属性置为false(客户端服务发现时不会发现)，如果某个实例超过30秒没有收到心跳，直接剔除该实例(被剔除的实例如果恢复发送心跳则会重新注册)

主流的注册中心对比

CAP C 一致性 A可用性 P 分区容错性

雪崩保护：

保护阈值： 设置0-1之间的值 0.6
临时实例： spring.cloud.nacos.discovery.ephemeral =false, 当服务宕机了也不会从服务列表中剔除
下图代表永久实例：

健康实例、 不健康实例；
健康实例数/总实例数 < 保护阈值`
1/2<0.6

结合负载均衡器 权重的机制， 设置的越大

Nacos 服务注册

Nacos 安装

查看上一篇文档 Mall 环境安装文档

执行流程图

搭建 Spring Cloud Alibaba 项目

pom 依赖

<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.1.2.RELEASE</version>
    </parent>
    <properties>
        <java.version>1.8</java.version>
        <spring-cloud.version>Greenwich.RELEASE</spring-cloud.version>
        <spring-cloud-alibaba.version>0.2.1.RELEASE</spring-cloud-alibaba.version>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.16.14</version>
            <scope>provided</scope>
        </dependency>
        <!--alibaba-nacos-discovery(阿里注册中心discovery)-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>
    </dependencies>
    <dependencyManagement>
        <dependencies>
            <!--Spring Cloud 相关依赖-->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>${spring-cloud.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <!--Spring Cloud Alibaba 相关依赖-->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-alibaba-dependencies</artifactId>
                <version>${spring-cloud-alibaba.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

配置文件 application.yml

spring:
    application:
        ## 注册服务名
        name: nacos-order
    cloud:
      nacos:
        ## 注册中心地址
        discovery:
          server-addr: 127.0.0.1:8848
server:
   ## 启动端口
    port: 8110

下面是 properties 配置

## 注册服务名
spring.application.name=nacos-order
## 注册中心地址
spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
## 启动端口
server.port=8111

同一个服务名，不同端口可以启动多个服务，可以做集群

创建启动类-OrderApp

说明：@EnableDiscoveryClient 是开启Spring Cloud的服务注册与发现

@SpringBootApplication
@EnableDiscoveryClient
public class OrderApp {
    public static void main(String[] args) {
        SpringApplication.run(OrderApp.class,args);
    }
}

启动成功可以看到控制台输出

Nacos 界面可以看到服务注册信息

Nacos 配置中心

默认配置中心

概述

下面我们通过一个简单的例子来介绍如何使用Nacos来创建配置内容以及如何在Spring Cloud应用中加载Nacos的配置信息。

Nacos 配置文件

第一步：进入Nacos的控制页面，在配置列表功能页面中，单击右上角的+按钮，进入新建配置页面，如图填写配置信息：
详解说明
其中：

• Data ID：填入nacos-order.ymal
• Group：默认值 DEFAULT_GROUP
• 配置格式：选择ymal
• 配置内容：应用要加载的配置内容，这里仅作为示例，做简单配置，比如：order.title=nacos-order配置中心

构建SpringCloudAlibaba Nacos配置中心项目

第一步：创建一个Spring Cloud应用，可以命名为：order-config。
第二步：编辑pom.xml，加入必要的依赖配置
项目搭建采用的版本是
spring-cloud版本是 Greenwich.RELEASE
spring-cloud-alibaba版本是 0.2.1.RELEASE
注意：
1.本项目采用parent模块化构建项目
2.如果你开发工具没有lombok插件，可以把pom中lombok依赖删除掉

pom.xml 依赖

<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.1.2.RELEASE</version>
    </parent>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.16.14</version>
            <scope>provided</scope>
        </dependency>
        <!--alibaba-nacos-discovery(阿里注册中心discovery)-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>
        <!--alibaba-config-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-alibaba-nacos-config</artifactId>
        </dependency>
    </dependencies>
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>Greenwich.RELEASE</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-alibaba-dependencies</artifactId>
                <version>0.2.1.RELEASE</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

配置文件

说明：配置文件加载顺序，SpringBoot中会先加载 bootstrap.yml，后加载 application.yml
注意：如果是yml配置文件，必须是 bootstrap.yml 而不是 application.yml

详解说明： 客户端配置，在bootstrap.yml文件中spring.cloud.nacos.config.file-extension属性声明从配置中心中读取的配置文件格式 该配置的缺省值为properties，即默认是读取properties格式的配置文件。当客户端没有配置该属性，并且在nacos server添加的是yml格式的配置文件，则给客户端会读取不到配置文件，导致启动失败。

server:
  ## 启动端口
  port: 8130
spring:
  application:
    ## 注册服务名
    name: nacos-order
  cloud:
    nacos:
      ## 注册中心地址
      discovery:
        server-addr: 127.0.0.1:8848
      ## 配置中心地址
      config:
        server-addr: 127.0.0.1:8848
        ## 指定读取配置文件的后缀
        file-extension: yaml
        ## 分组
        group: DEFAULT_GROUP

启动类

@SpringBootApplication
@EnableDiscoveryClient
public class OrderConfigApp {
    public static void main(String[] args) {
        SpringApplication.run(OrderConfigApp.class,args);
    }
}

测试类

其中通过 @Value 注解，注入了key为order.title的配置（默认为空字符串），这个配置会通过 /getOrder 接口返回，后续我们会通过这个接口来验证Nacos中配置的加载。另外，这里还有一个比较重要的注解@RefreshScope，主要用来让这个类下的配置内容支持动态刷新，也就是当我们的应用启动之后，修改了Nacos中的配置内容之后，这里也会马上生效。

/**
 * @author: LiPing.Zou
 * @create: 2020-05-18 15:27
 **/
@RestController
@RefreshScope
public class OrderController {
    @Value("${order.title}")
    private String orderTitle;
    @GetMapping("getOrder")
    public String getOrder(){
        return "order config" +orderTitle;
    }
}

控制台输出日志

浏览器访问，测试成功！

当我们修改配置中心内容，会触发 RefreshEventListener 事件

分组配置中心

概述

默认分组为DEFAULT_GROUP,Group 可以将不同的微服务进行分组划分。

Nacos 添加配置文件

配置文件

server:
  ## 启动端口
  port: 8160
spring:
  application:
    ## 注册服务名
    name: group-order-config
  cloud:
    nacos:
      ## 注册中心地址
      discovery:
        server-addr: 47.103.20.21:8848
      ## 配置中心地址
      config:
        server-addr: 47.103.20.21:8848
        ## 指定读取配置文件的后缀
        file-extension: yaml
        ## 分组
        group: DEV_GROUP

控制台输出

CompositePropertySource {name='NACOS', propertySources=[NacosPropertySource {name='namespace-order-config-dev.yaml'}, NacosPropertySource {name='namespace-order-config.yaml'}]}

测试结果

总结

• 优点：通过Group按环境讲各个应用的配置隔离开。可以非常方便的利用Data ID和Group的搜索功能，分别从应用纬度和环境纬度来查看配置。
• 缺点：由于会占用Group纬度，所以需要对Group的使用做好规划，毕竟与业务上的一些配置分组起冲突等问题。
• 建议：这种方式虽然结构上比上一种更好一些，但是依然可能会有一些混乱，主要是在Group的管理上要做好规划和控制。

命名空间配置中心

概述

默认为public,其作用可以用来实现环境隔离作用，比如我们的开发环境、测试环境、生产环境。

Nacos 添加命名空间

配置文件

添加了 namespace: 9e7bf496-2518-415c-9dcf-d2d47453457e

server:
  ## 启动端口
  port: 8180
spring:
  application:
    ## 注册服务名
    name: namespace-order-config
  cloud:
    nacos:
      ## 注册中心地址
      discovery:
        server-addr: 127.0.0.1:8848
      ## 配置中心地址
      config:
        server-addr: 127.0.0.1:8848
        ## 指定读取配置文件的后缀
        file-extension: yaml
        ## 命名空间
        namespace: 9e7bf496-2518-415c-9dcf-d2d47453457e

在新建 mall-test 命名空间新增配置

控制台输出

CompositePropertySource {name='NACOS', propertySources=[NacosPropertySource {name='namespace-order-config-dev.yaml'}, NacosPropertySource {name='namespace-order-config.yaml'}]}

测试结果

总结

• 优点：官方建议的方式，通过Namespace来区分不同的环境，释放了Group的自由度，这样可以让Group的使用专注于做业务层面的分组管理。同时，Nacos控制页面上对于Namespace也做了分组展示，不需要搜索，就可以隔离开不同的环境配置，非常易用。
• 缺点：没有啥缺点，可能就是多引入一个概念，需要用户去理解吧。
• 建议：直接用这种方式长远上来说会比较省心。虽然可能对小团队而言，项目不多，第一第二方式也够了，但是万一后面做大了呢？

多文件加载与共享配置

概述

有时候我们会对应用的配置根据具体作用做一些拆分，存储在不同的配置文件中，除了归类不同的配置之外，也可以便于共享配置给不同的应用。对于这样的需求，Nacos也可以很好的支持，下面就来具体介绍一下，当使用Nacos时，我们如何加载多个配置，以及如何共享配置。

配置中心添加两个配置文件

配置文件

group-share-config 服务同时加载两个配置文件 group-share-config.yaml, group-share-config2.yaml

server:
  ## 启动端口
  port: 8160
spring:
  application:
    ## 注册服务名
    name: group-share-config
  cloud:
    nacos:
      ## 注册中心地址
      discovery:
        server-addr: 127.0.0.1:8848
      ## 配置中心地址
      config:
        server-addr: 127.0.0.1:8848
#        ## 指定读取配置文件的后缀
#        file-extension: yaml
#        refreshable-dataids: group-share-config.yaml,group-share-config2.yaml
#        shared-dataids: group-share-config.yaml,group-share-config2.yaml
        ext-config:
          - data-id: group-share-config.yaml
            group: DEFAULT_GROUP
            refresh: true
            fileExtension: yaml
          - data-id: group-share-config2.yaml
            group: DEFAULT_GROUP
            refresh: true
            fileExtension: yaml

控制台输出

测试结果

Ribbon

什么是Ribbon

目前主流的负载方案分为以下两种：

• 集中式负载均衡，在消费者和服务提供方中间使用独立的代理方式进行负载，有硬件的（比如 F5），也有软件的（比如Nginx）。
• 客户端根据自己的请求情况做负载均衡，Ribbon 就属于客户端自己做负载均衡。

Spring Cloud Ribbon是基于Netflix Ribbon 实现的一套客户端的负载均衡工具，Ribbon客户端组件提供一系列的完善的配置，如超时，重试等。通过Load Balancer获取到服务提供的所有机器实例，Ribbon会自动基于某种规则(轮询，随机)去调用这些服务。Ribbon也可以实现我们自己的负载均衡算法。

客户端的负载均衡

例如 spring cloud中的 ribbon，客户端会有一个服务器地址列表，在发送请求前通过负载均衡算法选择一个服务器，然后进行访问，这是客户端负载均衡；即在客户端就进行负载均衡算法分配。

服务端的负载均衡

例如Nginx，通过Nginx进行负载均衡，先发送请求，然后通过负载均衡算法，在多个服务器之间选择一个进行访问；即在服务器端再进行负载均衡算法分配。

常见负载均衡算法

• 随机: 通过随机选择服务进行执行，一般这种方式使用较少;
• 轮训: 负载均衡默认实现方式，请求来之后排队处理;
• 加权轮训: 通过对服务器性能的分型，给高配置，低负载的服务器分配更高的权重，均衡各个服务器的压力;
• 地址Hash: 通过客户端请求的地址的HASH值取模映射进行服务器调度。 ip —->hash
• 最小链接数: 即使请求均衡了，压力不一定会均衡，最小连接数法就是根据服务器的情况，比如请求积压数等参数，将请求分配到当前压力最小的服务器上。 最小活跃数

Nacos 使用 Ribbon

nacos-discovery依赖了ribbon，可以不用再引入ribbon依赖

添加@LoadBalanced注解

@Configuration
public class RestTemplateConfig {
    @Bean
    @LoadBalanced
    public RestTemplate restTemplate(@Qualifier("simpleClientHttpRequestFactory") ClientHttpRequestFactory factory){
        return new RestTemplate(factory);
    }
    @Bean
    public ClientHttpRequestFactory simpleClientHttpRequestFactory(){
        SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
        factory.setConnectTimeout(85000);
        // 获取数据超时时间 毫秒
        factory.setReadTimeout(80000);
        return factory;
    }
}

修改接口实现类调用

private final RestTemplate restTemplate;
    @Override
    public Order addOrder() {
        Order order = new Order();
        order.setId(1);
        order.setName("ribbon 订单");
        order.setAmount(new BigDecimal("10098"));
//        String url = "http://127.0.0.1:8130/reduct";
        String url = "http://ribbon-stock/reduct";
        String object = restTemplate.getForObject(url, String.class);
        log.info("object={}",object);
        return order;
    }

Ribbon负载均衡策略

IRule
这是所有负载均衡策略的父接口，里边的核心方法就是choose方法，用来选择一个服务实例。
AbstractLoadBalancerRule
AbstractLoadBalancerRule是一个抽象类，里边主要定义了一个ILoadBalancer，这里定义它的目的主要是辅助负责均衡策略选取合适的服务端实例。

• RandomRule

看名字就知道，这种负载均衡策略就是随机选择一个服务实例，看源码我们知道，在RandomRule的无参构造方法中初始化了一个Random对象，然后在它重写的choose方法又调用了choose(ILoadBalancer lb, Object key)这个重载的choose方法，在这个重载的choose方法中，每次利用random对象生成一个不大于服务实例总数的随机数，并将该数作为下标所以获取一个服务实例。

• RoundRobinRule

RoundRobinRule这种负载均衡策略叫做线性轮询负载均衡策略。这个类的choose(ILoadBalancer lb, Object key)函数整体逻辑是这样的：开启一个计数器count，在while循环中遍历服务清单，获取清单之前先通过incrementAndGetModulo方法获取一个下标，这个下标是一个不断自增长的数先加1然后和服务清单总数取模之后获取到的（所以这个下标从来不会越界），拿着下标再去服务清单列表中取服务，每次循环计数器都会加
1，如果连续10次都没有取到服务，则会报一个警No available alive servers after 10 tries from load balancer: XXXX。

• RetryRule （在轮询的基础上进行重试）

看名字就知道这种负载均衡策略带有重试功能。首先RetryRule中又定义了一个subRule，它的实现类是RoundRobinRule，然后在RetryRule的choose(ILoadBalancer lb, Object key)方法中，每次还是采用RoundRobinRule中的choose规则来选择一个服务实例，如果选到的实例正常就返回，如果选择的服务实例为null或者已经失效，则在失效时间deadline之前不断的进行重试（重试时获取服务的策略还是RoundRobinRule中定义的策略），如果超过了deadline还是没取到则会返回一个null。

• WeightedResponseTimeRule（ 权重 —nacos的NacosRule ，Nacos还扩展了一个自己的基于配置的权重扩展 ）WeightedResponseTimeRule是RoundRobinRule的一个子类，在WeightedResponseTimeRule中对RoundRobinRule的功能进行了扩展，WeightedResponseTimeRule中会根据每一个实例的运行情况来给计算出该实例的一个权重，然后在挑选实例的时候则根据权重进行挑选，这样能够实现更优的实例调用。WeightedResponseTimeRule中有一个名叫DynamicServerWeightTask的定时任务，默认情况下每隔30秒会计算一次各个服务实例的权重，权重的计算规则也很简单，如果一个服务的平均响应时间越短则权重越大，那么该服务实例被选中执行任务的概率也就越大。

• ClientConfigEnabledRoundRobinRule

ClientConfigEnabledRoundRobinRule选择策略的实现很简单，内部定义了RoundRobinRule，choose方法还是采用了RoundRobinRule的choose方法，所以它的选择策略和RoundRobinRule的选择策略一致，不赘述。

• BestAvailableRule

BestAvailableRule继承自ClientConfigEnabledRoundRobinRule，它在ClientConfigEnabledRoundRobinRule的基础上主要增加了根据loadBalancerStats中保存的服务实例的状态信息来过滤掉失效的服务实例的功能，然后顺便找出并发请求最小的服务实例来使用。然而loadBalancerStats有可能为null，如果loadBalancerStats为null，则BestAvailableRule将采用它的父类即ClientConfigEnabledRoundRobinRule的服务选取策略（线性轮询）。

• ZoneAvoidanceRule （ 默认规则，复合判断server所在区域的性能和server的可用性选择服务器。 ）

ZoneAvoidanceRule是PredicateBasedRule的一个实现类，只不过这里多一个过滤条件，ZoneAvoidanceRule中的过滤条件是以ZoneAvoidancePredicate为主过滤条件和以AvailabilityPredicate 为次过滤条件组成的一个叫做CompositePredicate的组合过滤条件，过滤成功之后，继续采用线性轮询( RoundRobinRule )的方式从过滤结果中选择一个出来。

• AvailabilityFilteringRule（先过滤掉故障实例，再选择并发较小的实例）

  过滤掉一直连接失败的被标记为circuit tripped的后端Server，并过滤掉那些高并发的后端Server或者使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就是检查status里记录的各个Server的运行状态。

修改默认负载均衡策略

全局配置

@Configuration
public class RibbonConfig {
    @Bean
    public IRule iRule(){
        return new NacosRule();
    }
}

说明：不能写在@SpringbootApplication注解的@CompentScan扫描得到的地方，否则自定义的配置类就会被所有的RibbonClients共享。 不建议这么使用，推荐yml方式

自定义配置

@SpringBootApplication
@RibbonClients(value = {
        @RibbonClient(name="ribbon-stock",configuration = RibbonRandomRuleConfig.class)
})
public class OrderRibbonApp {
    public static void main(String[] args) {
        SpringApplication.run(OrderRibbonApp.class,args);
    }
}

RibbonRandomRuleConfig

@Configuration
public class RibbonRandomRuleConfig {
    /**
     * 方法名一定要叫iRule
     * @date: 2021/12/3 16:49
     * @return: com.netflix.loadbalancer.IRule
     */
    @Bean
    public IRule iRule(){
        return new RandomRule();
    }
}

yml 配置

# 被调用的微服务名
ribbon-stock:
  ribbon:
     # 指定使用Nacos提供的负载均衡策略（优先调用同一集群的实例，基于随机&权重）
    NFLoadBalancerRuleClassName: com.zlp.ribbon.rule

public class CustomRule extends AbstractLoadBalancerRule {
    @Override
    public Server choose(Object key) {
        ILoadBalancer loadBalancer = this.getLoadBalancer();
        // 获得当前请求的服务的实例
        List<Server> reachableServers = loadBalancer.getReachableServers();
        int random=ThreadLocalRandom.current().nextInt(reachableServers.size());
        Server server = reachableServers.get(random);
//        if(server.isAlive()){
//            return null;
//        }
        return server;
    }
    @Override
    public void initWithNiwsConfig(IClientConfig iClientConfig) {
    }
}

Ribbon内核原理

OpenFeign

JAVA 项目中如何实现接口调用？

Httpclient

HttpClient 是 Apache Jakarta Common 下的子项目，用来提供高效的、最新的、功能丰富的支持 Http 协议的客户端编程工具包，并且它支持 HTTP 协议最新版本和建议。HttpClient相比传统 JDK 自带的 URLConnection，提升了易用性和灵活性，使客户端发送 HTTP 请求变得容易，提高了开发的效率。

Okhttp

一个处理网络请求的开源项目，是安卓端最火的轻量级框架，由 Square 公司贡献，用于替代HttpUrlConnection 和 Apache HttpClient。OkHttp 拥有简洁的 API、高效的性能，并支持多种协议（HTTP/2 和 SPDY）。

HttpURLConnection

HttpURLConnection 是 Java 的标准类，它继承自 URLConnection，可用于向指定网站发送GET 请求、POST 请求。HttpURLConnection 使用比较复杂，不像 HttpClient 那样容易使用。

RestTemplate

RestTemplate 是 Spring 提供的用于访问 Rest 服务的客户端，RestTemplate 提供了多种便捷访问远程 HTTP 服务的方法，能够大大提高客户端的编写效率。上面介绍的是最常见的几种调用接口的方法，我们下面要介绍的方法比上面的更简单、方便，它就是 Feign。

什么是Feign

Feign是Netflix开发的声明式、模板化的HTTP客户端，其灵感来自Retrofit、JAXRS-2.0以及WebSocket。Feign可帮助我们更加便捷、优雅地调用HTTP API。

Feign支持多种注解，例如Feign自带的注解或者JAX-RS注解等。

Spring Cloud openfeign 对Feign进行了增强，使其支持Spring MVC注解，另外还整合了 Ribbon 和 Nacos，从而使得Feign的使用更加方便

优势

Feign 可以做到使用 HTTP 请求远程服务时就像调用本地方法一样的体验，开发者完全感知不到这是远程方法，更感知不到这是个 HTTP 请求。它像 Dubbo 一样，consumer 直接调用接口方法调用 provider，而不需要通过常规的 Http Client 构造请求再解析返回数据。它解决了让开发者调用远程接口就跟调用本地方法一样，无需关注与远程的交互细节，更无需关注分布式环境开发。

Spring Cloud Alibaba 快速整合 OpenFeign

引入依赖

<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

编写调用接口+@FeignClient注解

@FeignClient(value="feign-stock",contextId = "FeignStockService",path = "stock")
public interface FeignStockService {
    @GetMapping("/reductStock")
    String reductStock();
}

调用端在启动类上添加 @EnableFeignClients 注解

@EnableFeignClients
@SpringBootApplication
public class FeignOrderApp {
    public static void main(String[] args) {
        SpringApplication.run(FeignOrderApp.class,args);
    }
}

发起调用

@RestController
@RequestMapping("order")
@RequiredArgsConstructor
public class OrderController {
    private final FeignStockService feignStockService;
    @GetMapping("addOrder")
    public String addOrder(){
        String stock = feignStockService.reductStock();
        return "order remoe call feign stock=>"+stock;
    }
}

Spring Cloud Feign 的自定义配置及使用

Feign 提供了很多的扩展机制，让用户可以更加灵活的使用。

日志配置

有时候我们遇到 Bug，比如接口调用失败、参数没收到等问题，或者想看看调用性能，就需要
配置 Feign 的日志了，以此让 Feign 把请求信息输出来。

定义一个配置类，指定日志级别

/**
 * 此处配置@Configuration注解就会全局生效，如果想指定对应微服务生效，就不能配置
 * @date: 2021/12/7 20:03
 * @return: 
 */
@Configuration
public class FeignConfig {
    /**
     * 日志级别
     * <p>
     *     1. NONE【性能最佳，适用于生产】：不记录任何日志（默认值）。
     *     2. BASIC【适用于生产环境追踪问题】：仅记录请求方法、URL、响应状态代码以及
     *        执行时间。
     *     3. HEADERS：记录BASIC级别的基础上，记录请求和响应的header。
     *     4. FULL【比较适用于开发及测试环境定位问题】：记录请求和响应的header、body
     *       和元数据。
     * </p>
     * @date: 2021/12/6 20:40
     * @return: feign.Logger.Level
     */
    @Bean
    public Logger.Level feignLoggerLevel(){
        return Logger.Level.BASIC;
    }
}

通过源码可以看到日志等级有 4 种，分别是：

• NONE【性能最佳，适用于生产】：不记录任何日志（默认值）。
• BASIC【适用于生产环境追踪问题】：仅记录请求方法、URL、响应状态代码以及执行时间。
• HEADERS：记录BASIC级别的基础上，记录请求和响应的header。
• FULL【比较适用于开发及测试环境定位问题】：记录请求和响应的header、body 和元数据。

局部配置

让调用的微服务生效，在@FeignClient 注解中指定使用的配置类

/**
 * FeignStockService
 * @date: 2021/12/6 20:32
 */
@FeignClient(value="feign-stock",contextId = "FeignStockService",path = "stock",configuration = FeignConfig.class)
public interface FeignStockService {
    @GetMapping("/reductStock")
    String reductStock();
}

在 yml配置文件中执行 Client 的日志级别才能正常输出日志

# 日志
logging:
  level:
    com.zlp.feign.order.feign: debug

BASIC 级别日志

契约配置

Spring Cloud 在 Feign 的基础上做了扩展，使用 Spring MVC 的注解来完成Feign的功
能。原生的 Feign 是不支持 Spring MVC 注解的，如果你想在 Spring Cloud 中使用原生的
注解方式来定义客户端也是可以的，通过配置契约来改变这个配置，Spring Cloud 中默认的
是 SpringMvcContract。

Spring Cloud 1 早期版本就是用的原生Fegin. 随着netflix的停更替换成了Open feign

修改契约配置，支持Feign原生的注解

/**
  * 修改契约配置，支持Feign原生的注解
  * @return
  */
 @Bean
 public Contract feignContract() {
  return new Contract.Default();
 }

注意：修改契约配置后，OrderFeignService 不再支持springmvc的注解，需要使用Feign原生的注解

OrderFeignService 中配置使用Feign原生的注解

@FeignClient(value = "mall‐order",path = "/order")
public interface OrderFeignService {
  @RequestLine("GET /findOrderByUserId/{userId}")
  public R findOrderByUserId(@Param("userId") Integer userId);
}

自定义拦截器实现认证逻辑

控制拦截

/**
 * Feign 请求头拦截
 * @date: 2021/12/6 21:01
 */
@Configuration
@Slf4j(topic = "FeignRequestInterceptor")
public class FeignRequestInterceptor implements RequestInterceptor {
    @Override
    public void apply(RequestTemplate requestTemplate) {
        String accessToken = UUID.randomUUID().toString();
        log.info("accessToken={}",accessToken);
        requestTemplate.header("Authorization",accessToken);
    }
}

控制台输出

超时时间配置

通过 Options 可以配置连接超时时间和读取超时时间，Options 的第一个参数是连接的超时
时间（ms），默认值是 2s；第二个是请求处理的超时时间（ms），默认值是 5s。

全局配置

    /**
     *  超时配置
     * @date: 2021/12/7 20:20
     * @return: feign.Request.Options
     */
    @Bean
    public Request.Options options() {
        return new Request.Options(5000, 10000);
    }

yml 中配置

feign:
  client:
    config:
       # 连接超时时间，默认2s
      connectTimeout: 5000
       # 请求处理超时时间，默认5s
      readTimeout: 10000

测试超时情况：

Sentienl

nacos中open-feign

分布式遇到的问题

服务的可用性问题

服务的可用性场景

如果其中的下单服务不可用, 就会出现线程池里所有线程都因等待响应而被阻塞, 从而造成整个服务链路不可用， 进而导致整个系统的服务雪崩. 如图所示:
服务雪崩效应：因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程，就叫服务雪崩效应

导致服务不可用的原因：

在服务提供者不可用的时候，会出现大量重试的情况：用户重试、代码逻辑重试，这些重试最终导致：进一步加大请求流量。所以归根结底导致雪崩效应的最根本原因是：大量请求线程同步等待造成的资源耗尽。当服务调用者使用同步调用时, 会产生大量的等待线程占用系统资源。一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了。

解决方案

稳定性、恢复性

常见的容错机制：

超时机制

在不做任何处理的情况下，服务提供者不可用会导致消费者请求线程强制等待，而造成系统资源耗尽。加入超时机制，一旦超时，就释放资源。由于释放资源速度较快，一定程度上可以抑制资源耗尽的问题。

服务限流

隔离

原理：用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，则会进行降级处理，用户的请求不会被阻塞，至少可以看到一个执行结果（例如返回友好的提示信息），而不是无休止的等待或者看到系统崩溃。
隔离前：


隔离后：

信号隔离：
信号隔离也可以用于限制并发访问，防止阻塞扩散, 与线程隔离最大不同在于执行依赖代码的线程依然是请求线程（该线程需要通过信号申请, 如果客户端是可信的且可以快速返回，可以使用信号隔离替换线程隔离,降低开销。信号量的大小可以动态调整, 线程池大小不可以。

服务熔断

远程服务不稳定或网络抖动时暂时关闭，就叫服务熔断。
现实世界的断路器大家肯定都很了解，断路器实时监控电路的情况，如果发现电路电流异常，就会跳闸，从而防止电路被烧毁。
软件世界的断路器可以这样理解：实时监测应用，如果发现在一定时间内失败次数/失败率达到一定阈值，就“跳闸”，断路器打开——此时，请求直接返回，而不去调用原本调用的逻辑。跳闸一段时间后（例如10秒），断路器会进入半开状态，这是一个瞬间态，此时允许一次请求调用该调的逻辑，如果成功，则断路器关闭，应用正常调用；如果调用依然不成功，断路器继续回到打开状态，过段时间再进入半开状态尝试——通过”跳闸“，应用可以保护自己，而且避免浪费资源；而通过半开的设计，可实现应用的“自我修复“。

所以，同样的道理，当依赖的服务有大量超时时，在让新的请求去访问根本没有意义，只会无畏的消耗现有资源。比如我们设置了超时时间为1s,如果短时间内有大量请求在1s内都得不到响应，就意味着这个服务出现了异常，此时就没有必要再让其他的请求去访问这个依赖了，这个时候就应该使用断路器避免资源浪费.

服务降级

有服务熔断，必然要有服务降级。
所谓降级，就是当某个服务熔断之后，服务将不再被调用，此时客户端可以自己准备一个本地的fallback（回退）回调，返回一个缺省值。 例如：(备用接口/缓存/mock数据) 。这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强，当然这也要看适合的业务场景。

Sentinel 分布式系统流量防卫系统

Sentinel 是什么

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。

源码地址：https://github.com/alibaba/Sentinel
官方文档：https://github.com/alibaba/Sentinel/wiki

Sentinel具有以下特征:

• 丰富的应用场景： Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、实时熔断下游不可用应用等。
• 完备的实时监控： Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
• 广泛的开源生态： Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
• 完善的 SPI 扩展点： Sentinel 提供简单易用、完善的 SPI 扩展点。您可以通过实现扩展点，快速的定制逻辑。例如定制规则管理、适配数据源等。

Sentinel和Hystrix对比
https://github.com/alibaba/Sentinel/wiki/Sentinel­%E4%B8%8E­Hystrix­%E7%9A%84%E5%AF%B9%E6%AF%94

Sentinel 快速开始

https://github.com/alibaba/Sentinel/wiki/%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8
在官方文档中，定义的Sentinel进行资源保护的几个步骤：
1. 定义资源
2. 定义规则
3. 检验规则是否生效

Entry entry = null;
// 务必保证 finally 会被执行
try {
  // 资源名可使用任意有业务语义的字符串，注意数目不能太多（超过 1K），超出几千请作为参数传入而不要直接作为资源名
  // EntryType 代表流量类型（inbound/outbound），其中系统规则只对 IN 类型的埋点生效
  entry = SphU.entry("自定义资源名");
  // 被保护的业务逻辑
  // do something...
} catch (BlockException ex) {
  // 资源访问阻止，被限流或被降级
  // 进行相应的处理操作
} catch (Exception ex) {
  // 若需要配置降级规则，需要通过这种方式记录业务异常
  Tracer.traceEntry(ex, entry);
} finally {
  // 务必保证 exit，务必保证每个 entry 与 exit 配对
  if (entry != null) {
    entry.exit();
  }
}

Sentinel资源保护的方式

引入依赖

<dependency>
  <groupId>com.alibaba.csp</groupId>
 <artifactId>sentinel‐core</artifactId>
  <version>1.8.0</version>
</dependency>

编写测试逻辑

@RestController
@Slf4j(topic = "HelloController")
public class HelloController {
    private static final String RESOURCE_NAME = "hello";
    @RequestMapping(value = "/hello")
    public String hello() {
        Entry entry = null;
        try {
            // 资源名可使用任意有业务语义的字符串，比如方法名、接口名或其它可唯一标识的字符串。
            entry = SphU.entry(RESOURCE_NAME);
            // 被保护的业务逻辑
            String str = "hello world";
            log.info("=====" + str);
            return str;
        } catch (BlockException e1) {
            // 资源访问阻止，被限流或被降级
            //进行相应的处理操作
            log.info("block!");
        } catch (Exception ex) {
            // 若需要配置降级规则，需要通过这种方式记录业务异常
            Tracer.traceEntry(ex, entry);
        } finally {
            if (entry != null) {
                entry.exit();
            }
        }
        return null;
    }
    /**
     * 定义流控规则
     */
    @PostConstruct
    private static void initFlowRules() {
        List<FlowRule> rules = new ArrayList<>();
        FlowRule rule = new FlowRule();
        //设置受保护的资源
        rule.setResource(RESOURCE_NAME);
        // 设置流控规则 QPS
        rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
        // 设置受保护的资源阈值
        // Set limit QPS to 20.
        rule.setCount(1);
        rules.add(rule);
        // 加载配置好的规则
        FlowRuleManager.loadRules(rules);
    }
}

测试效果

缺点：

• 业务侵入性很强，需要在controller中写入非业务代码.
• 配置不灵活 若需要添加新的受保护资源 需要手动添加 init方法来添加流控规则

Sentinel 控制台

下载控制台 jar 包并在本地启动：可以参见 此处文档
https://github.com/alibaba/Sentinel/releases

启动控制台命令

java -jar sentinel‐dashboard‐1.8.0.jar

用户可以通过如下参数进行配置：
-Dsentinel.dashboard.auth.username=sentinel 用于指定控制台的登录用户名为 sentinel ；
-Dsentinel.dashboard.auth.password=123456 用于指定控制台的登录密码为 123456 ；如果省略这两个参数，默认用户和密码均为sentinel ；
-Dserver.servlet.session.timeout=7200 用于指定 Spring Boot 服务端 session 的过期时间，如 7200 表示 7200 秒； 60m 表示 60 分钟，默认为 30 分钟；

为了方便快捷启动可以在桌面创建.bat 文件

java -Dserver.port=8858 -Dsentinel.dashboard.auth.username=sentinel -Dsentinel.dashboard.auth.password=sentinel -jar D:\javaTools\Alibaba\sentinel\sentinel-dashboard-1.8.0.jar
paus

登入界面

访问http://127.0.0.1:8858 ,默认用户名密码： sentinel/sentinel

Sentinel 会在客户端首次调用的时候进行初始化，开始向控制台发送心跳包，所以要确保客户端有访问量；

Spring Cloud Alibaba 整合 Sentinel

引入依赖

 <dependency>
     <groupId>com.alibaba.cloud</groupId>
     <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
 <!--加入actuator-->
<dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

添加yml配置

为微服务设置 sentinel 控制台地址添加Sentinel后，需要暴露/actuator/sentinel端点,而Springboot默认是没有暴露该端点的，所以需要设置，测试 http://localhost:9110/actuator/sentinel

server:
  ## 启动端口
  port: 9110
spring:
  application:
    ## 注册服务名
    name: sentinel-order
  cloud:
    nacos:
      ## 注册中心地址
      discovery:
        server-addr: 127.0.0.1:8848
    ## sentinel config
    sentinel:
      transport:
        dashboard: localhost:8858
  main:
    allow-bean-definition-overriding: true
## 暴露端点
management:
  endpoints:
    web:
      exposure:
        include: '*'

在sentinel控制台中设置流控规则

sentinel 控制台中设置流控规则

• 资源名: 接口的API
• 针对来源: 默认是default，当多个微服务都调用这个资源时，可以配置微服务名来对指定的微服务设置阈值
• 阈值类型: 分为QPS和线程数 假设阈值为10
• QPS类型: 只得是每秒访问接口的次数>10就进行限流
• 线程数: 为接受请求该资源分配的线程数>10就进行限流

QPS 流控

测试： 因为QPS是1，所以1秒内多次访问会出现如下情形：

在访问 http://localhost:9110/actuator/sentinel 可以查看 flowRules (流控规则)

{
  "blockPage": null,
  "appName": "sentinel-order",
  "consoleServer": [
    {
      "r1": "localhost",
      "r2": 8858
    }
  ],
  "coldFactor": "3",
  "rules": {
    "systemRules": [
    ],
    "authorityRule": [
    ],
    "paramFlowRule": [
    ],
    "flowRules": [
      {
        "resource": "sayHello",
        "limitApp": "default",
        "grade": 1,
        "count": 1.0,
        "strategy": 0,
        "refResource": null,
        "controlBehavior": 0,
        "warmUpPeriodSec": 10,
        "maxQueueingTimeMs": 500,
        "clusterMode": false,
        "clusterConfig": {
          "flowId": null,
          "thresholdType": 0,
          "fallbackToLocalWhenFail": true,
          "strategy": 0,
          "sampleCount": 10,
          "windowIntervalMs": 1000
        }
      }
    ],
    "degradeRules": [
    ]
  },
  "metricsFileCharset": "UTF-8",
  "filter": {
    "order": -2147483648,
    "urlPatterns": [
      "/**"
    ],
    "enabled": true
  },
  "totalMetricsFileCount": 6,
  "datasource": {
  },
  "clientIp": "192.168.6.92",
  "clientPort": "8720",
  "logUsePid": false,
  "metricsFileSize": 52428800,
  "logDir": "C:\\Users\\user.DESKTOP-8A9L631\\logs\\csp\\","heartbeatIntervalMs":10000}

微服务和Sentinel Dashboard通信原理

Sentinel控制台与微服务端之间，实现了一套服务发现机制，集成了Sentinel的微服务都会将元数据传递给Sentinel控制台，架构图如下所示：
流控针对privoder 熔断降级 针对consumer

实时监控

监控接口的通过的QPS和拒绝的QPS

簇点链路

用来显示微服务的所监控的API

流控规则

流量控制

其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，
以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。
FlowRule RT(响应时间) 1/0.2s =5

同一个资源可以创建多条限流规则。 FlowSlot 会对该资源的所有限流规则依次遍历，直到有规则触发限流或者所有规则遍历完毕。一条限流规则主要由下面几个因素组成，我们可以组合这些元素来实现不同的限流效果。

• resource：资源名，即限流规则的作用对象
• count: 限流阈值
• grade: 限流阈值类型（QPS 或并发线程数）
• limitApp: 流控针对的调用来源，若为 default 则不区分调用来源
• strategy: 调用关系限流策略
• controlBehavior: 流量控制效果（直接拒绝、Warm Up、匀速排队）

参考文档： https://github.com/alibaba/Sentinel/wiki/%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6
限流阈值类型
QPS（Query Per Second）：每秒请求数，就是说服务器在一秒的时间内处理了多少个请求。

进入簇点链路选择具体的访问的API，然后点击流控按钮

并发线程数

并发数控制用于保护业务线程池不被慢调用耗尽。例如，当应用所依赖的下游应用由于某种原因导致服务不稳定、响应延迟增加，对于调用者来说，意味着吞吐量下降和更多的线程数占用，极端情况下甚至导致线程池耗尽。为应对太多线程占用的情况，业内有使用隔离的方案，比如通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢（线程池隔离）。这种隔离方案虽然隔离性比较好，但是代价就是线程数目太多，线程上下文切换的 overhead 比较大，特别是对低延时的调用有比较大的影响。Sentinel 并发控制不负责创建和管理线程池，而是简单统计当前请求上下文的线程数目（正在执行的调用数目），如果超出阈值，新的请求会被立即拒绝，效果类似于信号量隔离。并发数控制通常在调用端进行配置。

我们让代码休眠2s钟，连续访问接口 http://127.0.0.1:9110/flowThread

 @GetMapping("/flowThread")
    public String flowThread() throws InterruptedException {
        TimeUnit.SECONDS.sleep(2);
        log.info("flowThread======>正常访问");
        return "正常访问";
    }

页面返回结果

BlockException 异常统一处理

Springwebmvc 接口资源限流入口在 HandlerInterceptor的实现类 AbstractSentinelInterceptor 的preHandle方
法中，对异常的处理是 BlockExceptionHandler 的实现类

自定义BlockExceptionHandler 的实现类统一处理BlockException

/**
 * 自定义sentinel统一异常
 * @date: 2021/11/11 11:22
 */
@Component
@Slf4j(topic = "MyBlockExceptionHandler")
public class MyBlockExceptionHandler implements BlockExceptionHandler {
    @Override
    public void handle(HttpServletRequest httpServletRequest, HttpServletResponse response, BlockException e) throws Exception {
        log.info("handle BlockException:{}",e.getRule());
        RespCode respCode = null;
        if (e instanceof FlowException){
            respCode = RespCode.FLOW_EXCEPTION;
        }else if (e instanceof DegradeException) {
            respCode = RespCode.DEGRADE_EXCEPTION;
        }else if (e instanceof ParamFlowException) {
            respCode = RespCode.PARAM_FLOW_EXCEPTION;
        }else if (e instanceof SystemBlockException) {
            respCode = RespCode.SYSTEM_BLOCK_EXCEPTION;
        }else if (e instanceof AuthorityException) {
            respCode = RespCode.AUTHORITY_EXCEPTION;
        }
        response.setStatus(500);
        response.setCharacterEncoding("utf-8");
        response.setContentType(MediaType.APPLICATION_JSON_VALUE);
        response.getWriter().println(JSONUtil.parse(R.failed(respCode)));
        response.getWriter().flush();
    }
}

流控模式

基于调用关系的流量控制。调用关系包括调用方、被调用方；一个方法可能会调用其它方法，形成一个调用链路的层次关系。
直接
资源调用达到设置的阈值后直接被流控抛出异常

关联

当两个资源之间具有资源争抢或者依赖关系的时候，这两个资源便具有了关联。比如对数据库同一个字段的读操作和写操作存在争抢，读的速度过高会影响写得速度，写的速度过高会影响读的速度。如果放任读写操作争抢资源，则争抢本身带来的开销会降低整体的吞吐量。可使用关联限流来避免具有关联关系的资源之间过度的争抢，举例来说，read_db 和 write_db 这两个资源分别代表数据库读写，我们可以给 read_db 设置限流规则来达到写优先的目的：设置 strategy 为 RuleConstant.STRATEGY_RELATE 同时设置 refResource 为 write_db。这样当写库操作过于频繁时，读数据的请求会被限流。

链路

根据调用链路入口限流。
NodeSelectorSlot 中记录了资源之间的调用链路，这些资源通过调用关系，相互之间构成一棵调用树。这棵树的根节点是一个名字为 machine-root 的虚拟节点，调用链的入口都是这个虚节点的子节点。
一棵典型的调用树如下图所示：

                   machine-root
                    /       \
                   /         \
             Entrance1     Entrance2
                 /             \
                /               \
      DefaultNode(nodeA)   DefaultNode(nodeA)

上图中来自入口 Entrance1 和 Entrance2 的请求都调用到了资源 NodeA，Sentinel 允许只根据某个入口的统计信息对资源限流。

getUser 是实现类业务方法

测试会发现链路规则不生效
注意，高版本此功能直接使用不生效，如何解决？

从1.6.3版本开始，Sentinel Web filter默认收敛所有URL的入口context，导致链路限流不生效。 从1.7.0版本开始，官方在CommonFilter引入了WEB_CONTEXT_UNIFY参数，用于控制是否收敛context，将其配置为false即可根据不同的URL进行链路限流。

1.8.0 需要引入sentinel-web-servlet依赖

<!--- 解决流控链路不生效的问题-->
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-web-servlet</artifactId>
</dependency>

添加配置类，配置CommonFilter过滤器，指定WEB_CONTEXT_UNIFY=false，禁止收敛URL的入口context

@Configuration
public class SentinelConfig {
    @Bean
    public FilterRegistrationBean sentinelFilterRegistration() {
        FilterRegistrationBean registration = new FilterRegistrationBean();
        registration.setFilter(new CommonFilter());
        registration.addUrlPatterns("/*");
        // 入口资源关闭聚合   解决流控链路不生效的问题
        registration.addInitParameter(CommonFilter.WEB_CONTEXT_UNIFY, "false");
        registration.setName("sentinelFilter");
        registration.setOrder(1);
        return registration;
    }
}

再次测试链路规则，链路规则生效，但是出现异常

原因分析：
1. Sentinel流控规则的处理核心是 FlowSlot, 对getUser资源进行了限流保护，当请求QPS超过阈值2的时候，就会触发流控规则抛出FlowException异常
2. 对getUser资源保护的方式是@SentinelResource注解模式，会在对应的SentinelResourceAspect切面逻辑中处理BlockException类型的FlowException异常
（解决方案： 在@SentinelResource注解中指定blockHandler处理BlockException）

@Override
    @SentinelResource(value="getUser",blockHandler = "blockHandlerGetUser")
    public String getUser() {
        return "查询用户";
    }
    public String blockHandlerGetUser(BlockException e) {
        return "流控用户";
    }

流控效果

当 QPS 超过某个阈值的时候，则采取措施进行流量控制。流量控制的效果包括以下几种：快速失败（直接拒绝）、Warm Up（预热）、匀速排队（排队等待）。对应 FlowRule 中的 controlBehavior 字段。

快速失败

（RuleConstant.CONTROL_BEHAVIOR_DEFAULT）方式是默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException。这种方式适用于对系统处理能力确切已知的情况下，比如通过压测确定了系统的准确水位时。

Warm Up

Warm Up（RuleConstant.CONTROL_BEHAVIOR_WARM_UP）方式，即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过”冷启动”，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。
冷加载因子: codeFactor 默认是3，即请求 QPS 从 threshold / 3 开始，经预热时长逐渐升至设定的 QPS 阈值。
通常冷启动的过程系统允许通过的 QPS 曲线如下图所示

jmeter测试

查看实时监控，可以看到通过QPS存在缓慢增加的过程

匀速排队

匀速排队（RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER）方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。
该方式的作用如下图所示：

这种方式主要用于处理间隔性突发的流量，例如消息队列。想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求。

注意：匀速排队模式暂时不支持 QPS > 1000 的场景。

降级规则

除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。我们需要对不稳定的弱依赖服务调用进行熔断降级，暂时切断不稳定调用，避免局部不稳定因素导致整体的雪崩。熔断降级作为保护自身的手段，通常在客户端（调用端）进行配置。

熔断降级规则说明

熔断降级规则（DegradeRule）包含下面几个重要的属性：

熔断策略

慢调用比例

慢调用比例 (SLOW_REQUEST_RATIO)：选择以慢调用比例作为阈值，需要设置允许的慢调用 RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用。当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则会再次被熔断。

异常比例

异常比例 (ERROR_RATIO)：当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。

查看实时监控，可以看到断路器熔断效果

异常数

异常数 (ERROR_COUNT)：当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。
注意：异常降级仅针对业务异常，对 Sentinel 限流降级本身的异常（BlockException）不生效。

配置降级规则

热点参数限流

何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。比如：

• 商品 ID 为参数，统计一段时间内最常购买的商品 ID 并进行限制
• 用户 ID 为参数，针对一段时间内频繁访问的用户 ID 进行限制

热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。

注意：

1. 热点规则需要使用@SentinelResource(“resourceName”)注解，否则不生效
2. 参数必须是7种基本数据类型才会生效

测试用例

@RequestMapping("/info/{id}")
@SentinelResource(value = "userinfo",
                  blockHandlerClass = CommonBlockHandler.class,
                  blockHandler = "handleException2",
                  fallbackClass = CommonFallback.class,
                  fallback = "fallback"
                 )
public R info(@PathVariable("id") Integer id){
    UserEntity user = userService.getById(id);
    return R.ok().put("user", user);
}

配置热点参数规则
注意： 资源名必须是@SentinelResource(value=”资源名”)中 配置的资源名，热点规则依赖于注解

具体到参数值限流，配置参数值为3,限流阈值为1
测试：
http://localhost:8800/user/info/1 限流的阈值为3
http://localhost:8800/user/info/3 限流的阈值为1

系统规则

Sentinel 系统自适应限流从整体维度对应用入口流量进行控制，结合应用的 Load、CPU 使用率、总体平均 RT、入口 QPS 和并发线程数等几个维度的监控指标，通过自适应的流控策略，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

• Load 自适应（仅对 Linux/Unix-like 机器生效）：系统的 load1 作为启发指标，进行自适应系统保护。当系统 load1 超过设定的启发值，且系统当前的并发线程数超过估算的系统容量时才会触发系统保护（BBR 阶段）。系统容量由系统的 maxQps minRt 估算得出。设定参考值一般是 CPU cores 2.5。
• CPU usage（1.5.0+ 版本）：当系统 CPU 使用率超过阈值即触发系统保护（取值范围 0.0-1.0），比较灵敏。
• 平均 RT：当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
• 并发线程数：当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
• 入口 QPS：当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。

编写系统规则

openfeign 整合 sentinel

配置信息

feign:
  sentinel:
    # openfeign 整合 sentinel
    enabled: true

Feign 接口继承

@FeignClient(value="sentinel-stock",
        path = "/stock",
        contextId = "StockFeign",
        fallbackFactory = StockFeignServiceFallbackFactory.class
)
public interface StockFeign extends StockFeignService {
}
@Slf4j
@Component
public class StockFeignServiceFallbackFactory implements FallbackFactory<StockFeignService> {
    @Override
    public StockFeignService create(Throwable throwable) {
        return new StockFeignService() {
            @Override
            public String reduct(int orderId) {
                log.error("原因:{}", throwable.getMessage());
                return " 降级啦！！！";
            }
        };
    }
}

测试结果

Sentinel持久化模式

Sentinel规则的推送有下面三种模式:

原始模式

如果不做任何修改，Dashboard 的推送规则方式是通过 API 将规则推送至客户端并直接更
新到内存中：

这种做法的好处是简单，无依赖；坏处是应用重启规则就会消失，仅用于简单测试，不能
用于生产环境。

拉模式

pull 模式的数据源（如本地文件、RDBMS 等）一般是可写入的。使用时需要在客户端注册
数据源：将对应的读数据源注册至对应的 RuleManager，将写数据源注册至 transport 的
WritableDataSourceRegistry 中。

推模式

生产环境下一般更常用的是 push 模式的数据源。对于 push 模式的数据源,如远程配置中心
（ZooKeeper, Nacos, Apollo等等），推送的操作不应由 Sentinel 客户端进行，而应该经控
制台统一进行管理，直接进行推送，数据源仅负责获取配置中心推送的配置并更新到本
地。因此推送规则正确做法应该是 配置中心控制台/Sentinel 控制台 → 配置中心 →
Sentinel 数据源 → Sentinel，而不是经 Sentinel 数据源推送至配置中心。
这样的流程就非常清晰了：

基于Nacos配置中心控制台实现推送

官方demo: sentinel­demo­nacos­datasource

引入依赖

 <!--nacos 持久化-->
        <dependency>
            <groupId>com.alibaba.csp</groupId>
            <artifactId>sentinel-datasource-nacos</artifactId>
        </dependency>

nacos 配置中心中配置流控规则

[
  {
    "clusterMode": false,
    "controlBehavior": 0,
    "count": 1.0,
    "grade": 1,
    "limitApp": "default",
    "maxQueueingTimeMs": 500,
    "resource": "sayHello",
    "strategy": 0,
    "warmUpPeriodSec": 10
  }
]

yml 中配置

server:
  ## 启动端口
  port: 9110
spring:
  application:
    ## 注册服务名
    name: sentinel-order
  cloud:
    nacos:
      ## 注册中心地址
      discovery:
        server-addr: 127.0.0.1:8848
    ## sentinel config
    sentinel:
      transport:
        dashboard: localhost:8858
      datasource:
        sayhello-flow‐rules: #名称自定义，唯一
          nacos:
            server-addr: localhost:8858
            username: nacos
            password: nacos
            dataId: order-sentinel-flow-rule
            rule-type: flow
  main:
    allow-bean-definition-overriding: true
feign:
  sentinel:
    # openfeign 整合 sentinel
    enabled: true
## 暴露端点
management:
  endpoints:
    web:
      exposure:
        include: '*'