Spring Cloud Alibaba
- 第五部分 第二代 Spring Cloud 核心组件（SCA）
- 第 1 节 Nacos 服务注册和配置中心
- 1.1 Nacos 介绍
- 1.2 Nacos 单例服务部署
- 1.3 微服务注册到Nacos
- 1.4 负载均衡
- 1.5 Nacos 数据模型（领域模型）
- 1.6 Nacos 配置中心
- 1.6.1 Nacos Server添加配置
- 1.6.2 微服务中开启 Nacos 配置管理
- 第 2 节 SCA Sentinel 分布式系统的流量防卫兵
- 2.1 Sentinel 介绍
- 2.2 Sentinel 部署
- 2.3 服务改造
- 2.4 Sentinel 关键概念
- 2.5 Sentinel 流量规则模块
- 2.6 Sentinel 降级规则模块
- 2.7 SCA 小结
第五部分 第二代 Spring Cloud 核心组件（SCA）
SpringCloud 是若干个框架的集合，包括 spring-cloud-config、spring-cloud-bus 等近 20 个子项目，提供了服务治理、服务网关、智能路由、负载均衡、断路器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。Spring Cloud 通过 Spring Boot 风格的封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、容易部署的分布式系统开发工具包。一般来说，Spring Cloud 包含以下组件，主要以 Netflix 开源为主。
同 Spring Cloud 一样，Spring Cloud Alibaba 也是一套微服务解决方案，包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。依托Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。
阿里开源组件
- Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
- Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
- RocketMQ：开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。
- Dubbo：这个就不用多说了，在国内应用非常广泛的一款高性能 Java RPC 框架。
- Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
- Arthas：开源的Java动态追踪工具，基于字节码增强技术，功能非常强大。
阿里商业化组件
作为一家商业公司，阿里巴巴推出 Spring Cloud Alibaba，很大程度上市希望通过抢占开发者生态，来帮助推广自家的云产品。所以在开源社区，夹带了不少私货，阿里商业化组件，整体易用性和稳定性还是很高的。
Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。
Alibaba Cloud OSS：阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的云存储服务。
Alibaba Cloud SchedulerX：阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准的定时（基于 Cron 表达式）任务调度服务。
集成 Spring Cloud 组件
Spring Cloud Alibaba 作为整套的微服务解决组件，只依靠目前阿里的开源组件是不够的，更多的是集成当前的社区组件，所以 Spring Cloud Alibaba 可以集成 Zuul，GateWay等网关组件，也可继承Ribbon、OpenFeign等组件。
第 1 节 Nacos 服务注册和配置中心
1.1 Nacos 介绍
Nacos （Dynamic Naming and Configuration Service）是阿里巴巴开源的一个针对微服务架构中服务发现、配置管理和服务管理平台。
Nacos就是注册中心+配置中心的组合（Nacos=Eureka + Config + Bus）
官网：https://nacos.io 下载地址：https://github.com/alibaba/Nacos
Nacos功能特性
- 服务发现与健康检查
- 动态配置管理
- 动态DNS服务
- 服务和元数据管理（管理平台的角度，nacos也有一个ui页面，可以看到注册的服务及其实例信息（元数据信息）等），动态的服务权重调整、动态服务优雅下线，都可以去做
1.2 Nacos 单例服务部署
- 下载解压安装包，执行命令启动（我们使用最近比较稳定的版本 nacos-server-1.2.0.tar.gz）
linux/mac：sh startup.sh -m standalone windows：cmd startup.cmd - 访问nacos控制台：http://127.0.0.1:8848/nacos/#/login 或者http://127.0.0.1:8848/nacos/index.html（默认端口8848，账号和密码 nacos/nacos）
1.3 微服务注册到Nacos
-
在父pom中引入SCA依赖
<dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Greenwich.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> <!--SCA --> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>2.1.0.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> -
复制商品服务提供者工程，并引入nacos客户端依赖，必须删除eureka-client依赖
修改端口为9002<!-- nacos --> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency> -
application.yml修改，添加nacos配置信息
在yml文件中需要删除调用config和eureka相关的配置，否则启动失败spring: cloud: nacos: discovery: server-addr: localhost:8848 #nacos server 地址 -
启动商品微服务，观察nacos控制台
保护阈值：可以设置为0-1之间的浮点数，它其实是一个比例值（当前服务健康实例数/当前服务总实例数）场景：
一般流程下，nacos是服务注册中心，服务消费者要从nacos获取某一个服务的可用实例信息，对于服务实例有健康/不健康状态之分，nacos在返回给消费者实例信息的时候，会返回健康实例。这个时候在一些高并发、大流量场景下会存在一定的问题如果服务A有100个实例，98个实例都不健康了，只有2个实例是健康的，如果nacos只返回这两个健康实例的信息的话，那么后续消费者的请求将全部被分配到这两个实例，流量洪峰到来，2个健康的实例也扛不住了，整个服务A 就扛不住，上游的微服务也会导致崩溃，产生雪崩效应。
保护阈值的意义在于当服务A健康实例数/总实例数 < 保护阈值 的时候，说明健康实例真的不多了，这个时候保护阈值会被触发（状态true）
nacos将会把该服务所有的实例信息（健康的+不健康的）全部提供给消费者，消费者可能访问到不健康的实例，请求失败，但这样也比造成雪崩要好，牺牲了一些请求，保证了整个系统的一个可用。注意：阿里内部在使用nacos的时候，也经常调整这个保护阈值参数。
1.4 负载均衡
Nacos客户端引入的时候，会关联引入Ribbon的依赖包，我们使用OpenFiegn的时候也会引入
Ribbon的依赖，Ribbon包括Hystrix都按原来方式进行配置即可
此处，我们将商品微服务，再启动了一个9003端口，注册到Nacos上，便于测试负载均衡，我们通过后台也可以看出。
启动：
hyq-server-page-9101
hyq-server-product-9002
hyq-server-proudct-9003
测试：
http://localhost:9101/page/getPort
1.5 Nacos 数据模型（领域模型）
Namespace命名空间、Group分组、集群这些都是为了进行归类管理，把服务和配置文件进行归类，归类之后就可以实现一定的效果，比如隔离
比如，对于服务来说，不同命名空间中的服务不能够互相访问调用
- Namespace：命名空间，对不同的环境进行隔离，比如隔离开发环境、测试环境和生产环境
- Group：分组，将若干个服务或者若干个配置集归为一组，通常习惯一个系统归为一个组
- Service：某一个服务，比如商品微服务
- DataId：配置集或者可以认为是一个配置文件
Namespace + Group + Service 如同 Maven 中的GAV坐标，GAV坐标是为了锁定Jar，而这里是为了锁定服务
Namespace + Group + DataId 如同 Maven 中的GAV坐标，GAV坐标是为了锁定Jar，而这里是为了锁定配置文件
Nacos抽象出了Namespace、Group、Service、DataId等概念，具体代表什么取决于怎么用（非常灵活），推荐用法如下
| 概念 | 描述 |
|---|---|
| Namespace | 代表不同的环境，如开发dev、测试test、生产环境prod |
| Group | 代表某项目，比如xxx云项目 |
| Service | 某个项目中具体xxx服务 |
| DataId | 某个项目中具体的xxx配置文件 |
1.6 Nacos 配置中心
之前：Spring Cloud Config + Bus（配置的自动更新）
- Github 上添加配置文件
- 创建Config Server 配置中心—>从Github上去下载配置信息
- 具体的微服务(最终使用配置信息的)中配置Config Client—> ConfigServer获取配置信息
有Nacos之后，分布式配置就简单很多
Github不需要了（配置信息直接配置在Nacos server中），Bus也不需要了(依然可以完成动态刷新)
接下来
1、去Nacos server中添加配置信息
2、改造具体的微服务，使其成为Nacos Config Client，能够从Nacos Server中获取到配置信息
1.6.1 Nacos Server添加配置
1.6.2 微服务中开启 Nacos 配置管理
-
添加依赖
<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> </dependency> -
微服务中如何锁定 Nacos Server 中的配置文件（dataId）
通过 Namespace + Group + dataId 来锁定配置文件，Namespace不指定就默认public，Group不指定就默认 DEFAULT_GROUPdataId 的完整格式如下:
${prefix}-${spring.profile.active}.${file-extension} prefix 默认为 spring.application.name 的值，也可以通过配置项 spring.cloud.nacos.config.prefix 来配置。 spring.profile.active 即为当前环境对应的 profile。 注意：当 spring.profile.active 为空时，对应的连接符 - 也将不存在，dataId 的拼接格式变成 ${prefix}.${file-extension} file-exetension 为配置内容的数据格式，可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。 目前只支持 properties 和 yaml / yml 类型。注意：此时的配置文件的名字必须是： bootstrap.yml
server: port: 9101 # 后期该微服务多实例，端口从9100递增（10个以内） spring: application: name: hyq-service-page datasource: url: jdbc:mysql://localhost:3306/hyq?useUnicode=true&characterEncoding=utf8&serverTimezone=UTC&useSSL=false driver-class-name: com.mysql.jdbc.Driver username: root password: root cloud: nacos: discovery: server-addr: localhost:8848 config: server-addr: localhost:8848 file-extension: yaml # yml 也可以 -
通过 Spring Cloud 原生注解 @RefreshScope 实现配置自动更新
package com.hyq.page.controller; import org.springframework.beans.factory.annotation.Value; import org.springframework.cloud.context.config.annotation.RefreshScope; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController @RequestMapping("/config") @RefreshScope //自动刷新 public class ConfigClientController { @Value("${hyq.message}") private String message; @Value("${database.type}") private String dbType; @RequestMapping("/remote") public String findRemoteConfig() { return message + " " + dbType; } } -
思考：一个微服务希望从配置中心Nacos server中获取多个dataId的配置信息，可以的，扩展多个dataId
spring: cloud: nacos: discovery: server-addr: localhost:8848 # nacos config 配置 config: # 锁定server端的配置文件（读取它的配置项） namespace: ed505344-be50-4e2c-9e26-56d584e8bfc1 #命名空间的ID server-addr: localhost:8848 file-extension: yaml #默认properties group: DEFAULT_GROUP #如果使用的默认分组,可以不设置 # 根据规则拼接出来的dataId效果：hyq-service-page.yaml ext-config[0]: data-id: abc.yaml group: DEFAULT_GROUP refresh: true #开启扩展dataId的动态刷新 ext-config[1]: data-id: def.yaml group: DEFAULT_GROUP refresh: true #开启扩展dataId的动态刷新
第 2 节 SCA Sentinel 分布式系统的流量防卫兵
2.1 Sentinel 介绍
Sentinel是一个面向云原生微服务的流量控制、熔断降级组件。
替代Hystrix，针对问题：服务雪崩、服务降级、服务熔断、服务限流
Hystrix：
服务消费者（静态化微服务）—>调用服务提供者（商品微服务）
在调用方引入Hystrix
- 自己搭建监控平台 dashboard
- 没有提供UI界面进行服务熔断、服务降级等配置（使用的是@HystrixCommand参数进行设置，代码入侵）
Sentinel：
- 独立可部署Dashboard/控制台组件（其实就是一个jar文件，直接运行即可）
- 减少代码开发，通过UI界面配置即可完成细粒度控制
Sentinel 分为两个部分:
- 核心库：（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo /Spring Cloud 等框架也有较好的支持。
- 控制台：（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。
Sentinel 具有以下特征:
- 丰富的应用场景： Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
- 完备的实时监控： Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
- 广泛的开源生态： Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring
Cloud、Dubbo的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。 - 完善的 SPI 扩展点： Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
Sentinel 的主要特性：
Sentinel 的开源生态：
2.2 Sentinel 部署
下载地址：
https://github.com/alibaba/Sentinel/releases/tag/1.7.1
我们使用v1.7.1
启动：java -jar sentinel-dashboard-1.7.1.jar
用户名/密码：sentinel/sentinel
2.3 服务改造
在我们已有的业务场景中，“静态化微服务”调用了“商品微服务”，我们在静态化微服务进行的熔断降级等控制，那么接下来我们改造静态化微服务，引入Sentinel核心包。
为了不污染之前的代码，复制一个页面静态化微服务 hyq-service-page-9102-sentinel
- pom.xml引入依赖
<!--sentinel 核心环境 依赖--> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId> </dependency> - bootstrap.yml修改（配置sentinel dashboard，暴露断点依然要有，删除原有hystrix配置，删除原有OpenFeign的降级配置）
server: port: 9102 # 后期该微服务多实例，端口从9100递增（10个以内） spring: main: #解决bean重复注册问题 allow-bean-definition-overriding: true application: name: hyq-service-page datasource: url: jdbc:mysql://localhost:3306/hyq?useUnicode=true&characterEncoding=utf8&serverTimezone=UTC&useSSL=false driver-class-name: com.mysql.jdbc.Driver username: root password: root cloud: nacos: discovery: server-addr: localhost:8848 # nacos config 配置 config: # 锁定server端的配置文件（读取它的配置项） namespace: ed505344-be50-4e2c-9e26-56d584e8bfc1 #命名空间的ID server-addr: localhost:8848 file-extension: yaml #默认properties group: DEFAULT_GROUP #如果使用的默认分组,可以不设置 #sentinel配置 sentinel: transport: dashboard: localhost:8080 port: 8719 # 8719端口就是未来微服务与Sentinel组件对应的操作端口。 # springboot中暴露健康检查等断点接口 management: endpoints: web: exposure: include: "*" # 暴露健康接口的细节 endpoint: health: show-details: always
上述配置之后，启动静态化微服务，使用 Sentinel 监控静态化微服务
此时我们发现控制台没有任何变化，因为懒加载，我们只需要发起一次请求触发即可
2.4 Sentinel 关键概念
| 概念名称 | 概念描述 |
|---|---|
| 资源 | 它可以是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它应用提供的服务，甚至可以是一段代码。我们请求的API接口就是资源 |
| 规则 | 围绕资源的实时状态设定的规则，可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。 |
2.5 Sentinel 流量规则模块
系统并发能力有限，比如系统A的QPS支持1个，如果太多请求过来，那么A就应该进行流量控制了，比如其他请求直接拒绝
-
资源名：默认请求路径
-
针对来源：Sentinel可以针对调用者进行限流，填写微服务名称，默认default（不区分来源）
-
阈值类型/单机阈值
- QPS：（每秒钟请求数量）当调用该资源的QPS达到阈值时进行限流
- 线程数：当调用该资源的线程数达到阈值的时候进行限流（线程处理请求的时候，如果说业务逻辑执行时间很长，流量洪峰来临时，会耗费很多线程资源，这些线程资源会堆积，最终可能造成服务不可用，进一步上游服务不可用，最终可能服务雪崩）
-
是否集群：是否集群限流
-
流控模式：
- 直接：资源调用达到限流条件时，直接限流
- 关联：关联的资源调用达到阈值时候限流自己
- 链路：只记录指定链路上的流量
-
流控效果：
- 快速失败：直接失败，抛出异常
- Warm Up：根据冷加载因子（默认3）的值，从阈值/冷加载因子，经过预热时长，才达到设置的QPS阈值
- 排队等待：匀速排队，让请求匀速通过，阈值类型必须设置为QPS，否则无效
-
流控模式之关联限流
关联的资源调用达到阈值时候限流自己，比如用户注册接口，需要调用身份证校验接口（往往身份证校验接口），如果身份证校验接口请求达到阈值，使用关联，可以对用户注册接口进行限流。
package com.hyq.page.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController @RequestMapping("/user") public class UserController { /** * 用户注册接口 * @return */ @GetMapping("/register") public String register() { System.out.println("Register success!"); return "Register success!"; } /** * 验证注册身份证接口（需要调用公安户籍资源） * @return */ @GetMapping("/validateID") public String validateID() { System.out.println("validateID"); return "ValidateID success!"; } }模拟密集式请求/user/validateID验证接口，我们会发现/user/register接口也被限流了
-
流控模式之链路限流
链路指的是请求链路（调用链：A–>B–C，D–>E–>C）链路模式下会控制该资源所在的调用链路入口的流量。需要在规则中配置入口资源，即该调用链路入口的上下文名称。
一棵典型的调用树如下图所示：
上图中来自入口 Entrance1 和 Entrance2 的请求都调用到了资源 NodeA ，Sentinel 允许只根据某个调用入口的统计信息对资源限流。比如链路模式下设置入口资源为 Entrance1 来表示只有从入口Entrance1 的调用才会记录到 NodeA 的限流统计当中，而不关心经 Entrance2 到来的调用。
-
流控效果之Warm up
当系统长期处于空闲的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮，比如电商网站的秒杀模块。通过 Warm Up 模式（预热模式），让通过的流量缓慢增加，经过设置的预热时间以后，到达系统处理请求速率的设定值。
Warm Up 模式默认会从设置的 QPS 阈值的 1/3 开始慢慢往上增加至 QPS 设置值。
-
流控效果之排队等待
排队等待模式下会严格控制请求通过的间隔时间，即请求会匀速通过，允许部分请求排队等待，通常用于消息队列削峰填谷等场景。需设置具体的超时时间，当计算的等待时间超过超时时间时请求就会被拒绝。很多流量过来了，并不是直接拒绝请求，而是请求进行排队，一个一个匀速通过（处理），请求能等就等着被处理，不能等（等待时间>超时时间）就会被拒绝
例如，QPS 配置为 5，则代表请求每 200 ms 才能通过一个，多出的请求将排队等待通过。超时时间代表最大排队时间，超出最大排队时间的请求将会直接被拒绝。排队等待模式下，QPS 设置值不要超过 1000（请求间隔 1 ms）。
2.6 Sentinel 降级规则模块
流控是对外部来的大流量进行控制，熔断降级的视角是对内部问题进行处理。
Sentinel 降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断，这里的降级其实是Hystrix中的熔断策略
Sentinel不会像Hystrix那样放过一个请求尝试自我修复，就是明明确确按照时间窗口来，熔断触发后，时间窗口内拒绝请求，时间窗口后就恢复。
- RT（平均响应时间 ）
当 1s 内持续进入 >=5 个请求，平均响应时间超过阈值（以 ms 为单位），那么在接下的时间窗口（以 s 为单位）之内，对这个方法的调用都会自动地熔断（抛出 DegradeException）。注意Sentinel 默认统计的 RT 上限是 4900 ms，超出此阈值的都会算作 4900 ms，若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。
- 异常比例
当资源的每秒请求量 >= 5，并且每秒异常总数占通过量的比值超过阈值之后，资源进入降级状态，即在接下的时间窗口（以 s 为单位）之内，对这个方法的调用都会自动地返回。异常比率的阈值范围是[0.0, 1.0] ，代表 0% - 100%。
- 异常数
当资源近 1 分钟的异常数目超过阈值之后会进行熔断。注意由于统计时间窗口是分钟级别的，若timeWindow 小于 60s，则结束熔断状态后仍可能再进入熔断状态，时间窗口 >= 60s。
2.7 SCA 小结
SCA实际上发展了三条线
第一条线：开源出来一些组件
第二条线：阿里内部维护了一个分支，自己业务线使用
第三条线：阿里云平台部署一套，付费使用
从战略上来说，SCA更是为了贴合阿里云。
目前来看，开源出来的这些组件，推广及普及率不高，社区活跃度不高，稳定性和体验度上仍需进一步提升，根据实际使用来看Sentinel的稳定性和体验度要好于Nacos。
