分布式微服务技术搭配方案(Spring Cloud + SpringCloud Alibaba组件配置及使用)

SpringCloud 的几大痛点

• SpringCloud 部分组件停止维护和更新，给开发带来不便；
• SpringCloud 部分环境搭建复杂，没有完善的可视化界面，我们需要大量的二次开发和定制
• SpringCloud 配置复杂，难以上手，部分配置差别难以区分和合理应用

SpringCloud Alibaba 的优势

阿里使用过的组件经历了考验，性能强悍，设计合理，现在开源出来大家用 成套的产品搭配完善的可视化界面给开发运维带来极大的便利搭建简单，学习曲线低。

分布式微服务全套解决方案

结合 SpringCloud Alibaba 我们最终的技术搭配方案：

• SpringCloud Alibaba - Nacos：注册中心（服务发现/注册）
• SpringCloud Alibaba - Nacos：配置中心（动态配置管理）
• SpringCloud - Ribbon：负载均衡
• SpringCloud - Feign：声明式 HTTP 客户端（调用远程服务）
• SpringCloud Alibaba - Sentinel：服务容错（限流、降级、熔断）
• SpringCloud - Gateway：API 网关（webflux 编程模式）
• SpringCloud - Sleuth：调用链监控
• SpringCloud Alibaba - Seata：原 Fescar，即分布式事务解决方案

一、SpringCloud Alibaba

1）、简介

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

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

https://github.com/alibaba/spring-cloud-alibaba

2）、为什么使用

3）、版本选择

由于 Spring Boot 1 和 Spring Boot 2 在 Actuator 模块的接口和注解有很大的变更，且 spring-cloud-commons 从 1.x.x 版本升级到 2.0.0 版本也有较大的变更，因此我们采取跟 SpringBoot 版本号一致的版本:  1.5.x 版本适用于 Spring Boot 1.5.x  2.0.x 版本适用于 Spring Boot 2.0.x  2.1.x 版本适用于 Spring Boot 2.1.x

4）、项目中的依赖

在 common 项目中引入如下。进行统一管理

<dependencyManagement> 
	<dependencies> 
		<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>

2、SpringCloud Alibaba-Nacos[作为注册中心]

Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理 平台。他是使用 java 编写。需要依赖 java 环境
Nacos 文档地址： https://nacos.io/zh-cn/docs/quick-start.html

1）、下载

nacos-server https://github.com/alibaba/nacos/releases

2）、启动 nacos-server

• 双击 bin 中的 startup.cmd 文件
• 访问 http://localhost:8848/nacos/
• 使用默认的 nacos/nacos 进行登录
  

3）、将微服务注册到 nacos 中

1、pom.xml 引入 Nacos Discovery Starter。

<dependency> 
	<groupId>com.alibaba.cloud</groupId>
	<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency>

2、在应用的 /src/main/resources/application.properties 配置文 件中配置 Nacos Server 地址

spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848

3、使用@EnableDiscoveryClient 开启服务注册发现功能

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

4、启动应用，观察 nacos 服务列表是否已经注册上服务

注意：每一个应用都应该有名字，这样才能注册上去。修改 application.properties 文件

spring.application.name=service-provider server.port=8000

5、注册更多的服务上去，测试使用 feign 远程调用

Nacos 使用三步
1、导包 nacos-discovery
2、写配置，指定 nacos 地址，指定应用的名字
3、开启服务注册发现功能@EnableDiscoveryClient

Feign 使用三步
1、导包 openfeign
2、开启@EnableFeignClients 功能
3、编写接口，进行远程调用

@FeignClient("stores") 
public interface StoreClient {
    
	@RequestMapping(method = RequestMethod.GET, value = "/stores") 
	List<Store> getStores(); 

	@RequestMapping(method = RequestMethod.POST, value = "/stores/{storeId}", consumes = "application/json") 
	Store update(@PathVariable("storeId") Long storeId, Store store); 
}

6、更多配置

https://github.com/alibaba/spring-cloud-alibaba/blob/master/spring-cloud-alibaba-examples/na cos-example/nacos-discovery-example/readme-zh.md#more

3、SpringCloud Alibaba-Nacos[作为配置中心]

1、pom.xml 引入 Nacos Config Starter。

<dependency> 
	<groupId>com.alibaba.cloud</groupId> 
	<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> 
</dependency>

2、在应用的 /src/main/resources/bootstrap.properties 配 置文件中配置 Nacos Config 元数据

spring.application.name=nacos-config-example 
spring.cloud.nacos.config.server-addr=127.0.0.1:8848 

主要配置应用名和配置中心地址

3、在 nacos 中添加配置 在 nacos 中创建一个 应用名.properties 配置文件并编写配置

Nacos Config 数据结构
Nacos Config 主要通过 dataId 和 group 来唯一确定一条配置。 
Nacos Client 从 Nacos Server 端获取数据时，调用的是此接口 ConfigService.getConfig(String dataId, String group, long timeoutMs)。

Spring Cloud 应用获取数据 

dataID： 
在 Nacos Config Starter 中，dataId 的拼接格式如下 
	- ${prefix} - ${spring.profiles.active} . ${file-extension} prefix 默认为 spring.application.name 的值，也可以通过配置项 spring.cloud.nacos.config.prefix 来配置。 
	- spring.profiles.active 即为当前环境对应的 profile 注意，当 activeprofile 为空时，对应的连接符 - 也将不存在，dataId 的拼接格式变成 ${prefix}.${file-extension} 
	- file-extension 为配置内容的数据格式，可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。 目前只支持 properties 类型。 

Group：
Group 默认为 DEFAULT_GROUP，可以通过 spring.cloud.nacos.config.group 配置。

4、在应用中使用**@Value** 和**@RefreshScope**

完成上述两步后，应用会从Nacos Config中获取相应的配置，并添加在Spring Environment的 PropertySources中。这里我们使用@Value注解来将对应的配置注入到SampleController的 userName和age字段，并添加@RefreshScope打开动态刷新功能

@RefreshScope 
class SampleController {
   
	 @Value("${user.name}") 
 	String userName; 

	@Value("${user.age}") 
	int age; 
}

5、进阶

1、核心概念

命名空间：
用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的 配置。Namespace 的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生 产环境的资源（如配置、服务）隔离等。

配置集： 
一组相关或者不相关的配置项的集合称为配置集。在系统中，一个配置文件通常就是一个配 置集，包含了系统各个方面的配置。例如，一个配置集可能包含了数据源、线程池、日志级 别等配置项。

配置集 ID： 
Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组 织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有 意义的名称标识。Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名 规则保证全局唯一性。此命名规则非强制。 

配置分组：
Nacos 中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个 配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置 分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。

2、原理

自动注入： 
NacosConfigStarter 实现了 org.springframework.cloud.bootstrap.config.PropertySourceLocator 接口，并将优先级设置成了最高。 
在 Spring Cloud 应用启动阶段，会主动从 Nacos Server 端获取对应的数据，并将获取到的 数据转换成 PropertySource 且注入到 Environment 的 PropertySources 属性中，所以使用 @Value 注解也能直接获取 Nacos Server 端配置的内容。

动态刷新： Nacos Config Starter 默认为所有获取数据成功的 Nacos 的配置项添加了监听功能，在监听 到服务端配置发生变化时会实时触发 org.springframework.cloud.context.refresh.ContextRefresher 的 refresh 方法 。 
如果需要对 Bean 进行动态刷新，请参照 Spring 和 Spring Cloud 规范。推荐给类添加@RefreshScope 或 @ConfigurationProperties 注解

3、加载多配置文件

spring.cloud.nacos.config.server-addr=127.0.0.1:8848 spring.cloud.nacos.config.namespace=31098de9-fa28-41c9-b0bd-c754ce319ed4 spring.cloud.nacos.config.ext-config[0].data-id=gulimall-datasource.yml spring.cloud.nacos.config.ext-config[0].refresh=false spring.cloud.nacos.config.ext-config[0].group=dev

4、namespace 与 group 最佳实践

每个微服务创建自己的 namespace 进行隔离，group 来区分 dev，beta，prod 等环境

4、SpringCloud Alibaba-Sentinel

1、简介

Sentinel 是面向分布式服务架构的流量控制组件,主要以流量为切入点,从流量控制、熔断降级、系统自适应保护等多个维度来帮助您保障微服务的稳定性

官方文档：https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D
项目地址：https://github.com/alibaba/Sentinel
随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点， 从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

Sentinel 具有以下特征:
丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场 景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集 群流量控制、实时熔断下游不可用应用等。

完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入 应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。

广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如 与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配 置即可快速地接入 Sentinel。

完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过 实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

Sentinel 分为两个部分:

• 核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时 对 Dubbo / Spring Cloud 等框架也有较好的支持。
• 控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。

Sentinel 基本概念

• 资源
  资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，例如，由应用程序提 供的服务，或由应用程序调用的其它应用提供的服务，甚至可以是一段代码。在接下来的文档中，我们都会用资源来描述代码块。

只要通过 Sentinel API 定义的代码，就是资源，能够被 Sentinel 保护起来。大部分情况下， 可以使用方法签名，URL，甚至服务名称作为资源名来标示资源。

• 规则
  围绕资源的实时状态设定的规则，可以包括流量控制规则、熔断降级规则以及系统保护规 则。所有规则可以动态实时调整。

2、Hystrix 与 Sentinel 比较

3、整合 Feign+Sentinel 测试熔断降级 https://github.com/alibaba/Sentinel/wiki/%E4%B8%BB%E9%A1%B5

熔断降级限流
除了流量控制以外，降低调用链路中的不稳定资源也是 Sentinel 的使命之一。由于调用关 系的复杂性，如果调用链路中的某个资源出现了不稳定，最终会导致请求发生堆积。

什么是熔断
A 服务调用 B 服务的某个功能，由于网络不稳定问题，或者 B 服务卡机，导致功能时 间超长。如果这样子的次数太多。我们就可以直接将 B 断路了（A 不再请求 B 接口），凡是 调用 B 的直接返回降级数据，不必等待 B 的超长执行。 这样 B 的故障问题，就不会级联影响到 A。

什么是降级
整个网站处于流量高峰期，服务器压力剧增，根据当前业务情况及流量，对一些服务和 页面进行有策略的降级[停止服务，所有的调用直接返回降级数据]。以此缓解服务器资源的 的压力，以保证核心业务的正常运行，同时也保持了客户和大部分客户的得到正确的相应。

异同：
相同点：
1、为了保证集群大部分服务的可用性和可靠性，防止崩溃，牺牲小我
2、用户最终都是体验到某个功能不可用
不同点：
1、熔断是被调用方故障，触发的系统主动规则
2、降级是基于全局考虑，停止一些正常服务，释放资源

什么是限流
对打入服务的请求流量进行控制，使服务能够承担不超过自己能力的流量压力

Sentinel 和 Hystrix 的原则是一致的: 当检测到调用链路中某个资源出现不稳定的表现，例 如请求响应时间长或异常比例升高的时候，则对这个资源的调用进行限制，让请求快速失败， 避免影响到其它的资源而导致级联故障。

熔断降级设计理念
在限制的手段上，Sentinel 和 Hystrix 采取了完全不一样的方法。

Hystrix 通过 线程池隔离 的方式，来对依赖（在 Sentinel 的概念中对应 资源）进行了隔 离。这样做的好处是资源和资源之间做到了最彻底的隔离。缺点是除了增加了线程切换的成 本（过多的线程池导致线程数目过多），还需要预先给各个资源做线程池大小的分配。

Sentinel 对这个问题采取了两种手段:

• 通过并发线程数进行限制 和资源池隔离的方法不同，Sentinel 通过限制资源并发线程的数量，来减少不稳定资源对其 它资源的影响。这样不但没有线程切换的损耗，也不需要您预先分配线程池的大小。当某个 资源出现不稳定的情况下，例如响应时间变长，对资源的直接影响就是会造成线程数的逐步 堆积。当线程数在特定资源上堆积到一定的数量之后，对该资源的新请求就会被拒绝。堆积 的线程完成任务后才开始继续接收请求。

• 通过响应时间对资源进行降级 除了对并发线程数进行控制以外，Sentinel 还可以通过响应时间来快速降级不稳定的资源。 当依赖的资源出现响应时间过长后，所有对该资源的访问都会被直接拒绝，直到过了指定的 时间窗口之后才重新恢复。

整合测试： https://github.com/alibaba/spring-cloud-alibaba/blob/master/spring-cloud-alibaba-examples/se ntinel-example/sentinel-feign-example/readme-zh.md

1、引入依赖

<dependency> 
	<groupId>org.