目录
服务调用_Dubbo实现服务降级
设置服务生产者集群容错模式
@DubboService(timeout = 5000,
version = "1.0",
methods = {@Method(name = "index",retries = 2)},
// 快速失败模式，调用只执行一次，失败则立即报错。
cluster = "failfast")
public class PaymentServiceImpl implements IPaymentService {
@Override
public String index() {
return "hello dubbo payment";
}
} 
编写降级实现类
public class PaymentFallback implements IPaymentService {
//降级方法
@Override
public String index() {
return "服务繁忙请稍后再试！";
}
}编写订单业务层
@Service
public class PaymentServiceImpl {
@DubboReference(version = "1.0",
mock = "com.tong.service.PaymentFallback",
// 快速失败,去查询集群中其他机器
cluster = "failfast")
IPaymentService iPaymentService;
public String index() {
return iPaymentService.index();
}
}
注意： 该处mock直接配置服务降级类的全路径。
测试
故意关闭订单支付生产者服务。请求http://localhost:80/order/index
实时效果反馈
1.Dubbo技术中如何实现服务降级_____。
A Hystrix
B Resilience4j
C mock
D 以上都是错误
分布式配置中心_为什么需要分布式配置中心
为什么需要分布式配置中心
作为一个开发人员，对配置文件都不陌生。在Spring项目中，默认 提供了一个application.yml或者application.properties。
注意： 把各个服务的某些配置信息统一交给第三方中间件来维护，分布式配置管理上的数据变变更，需要实时地推送到相对应的应用服务节点上。
实时效果反馈
1.不使用分布式配置中心有那些缺点是_____。
A 不支持配置文件的动态更新
B 不支持配置集中式管理
C 不支持多环境部署
D 以上都是正确
分布式配置中心_了解主流的配置中心
主流的分布式配置中心有以下三种，其中，Nacos是Alibaba开源的分布式配置中心。
Nacos
这是SpingCloud alibaba技术栈中的一个组件，前面我们已经使用它做过服务注册中心。其实它也集成了服务配置的功能，我们可以直接使用它作为服务配置中心。
应用和配置中心间的数据同步通常如下三种模式:
Pull模式：让应用开后长轮询，即定时地从配置中心拉取最新的配置信息，并更新到应用的内存 中。
Push模式：在配置中心配置数据变更之后，主动推送配置数据到指定的应用，应用更新到本地内 存中。
混合模式：应用和配置中心通过“事件机制＋监听器”模式保持长连接。如果应用监听的配置信息发 生了变化，则配置中心发布对应类型的事件。应用只有在监听到该事件之后,才会处理对应的配置信 息，并更新到应用本地。
Apollo
Apollo是由携程开源的分布式配置中心。特点有很多，比如：配置更新之后可以实时生效，支持灰度发布功能，并且能对所有的配置 进行版本管理、操作审计等功能，提供开放平台API。携程的分布式 配置中心框架,有图形界面可以管理配置文件信息,配置文件信息存放 在数据库中。
Spring Cloud Config
它和Spring是无缝集成，使用起来非常方便，并且它的配置存储支 持Git。不过它没有可视化的操作界面，配置的生效也不是实时的， 需要重启或去刷新。
分布式配置中心对比
实时效果反馈
1.下列不属于分布式配置中心技术的是_____。
A Nacos
B Apollo
C SpringCloud Config
D Gateway
2.下列Nacos技术中应用和配置中心间的数据同步常用的三种模式是_____。
A Pull模式
B Push模式
C 混合模式
D 以上都是正确
分布式配置中心_Namespace命名空间
前言
现如今，在微服务体系中，一个系统往往被拆分为多个服务，每个服务都有自己的配置文件，然后每个系统往往还会准备开发环境、 测试环境、正式环境。
问题： 我们来说算一算，假设某系统有10个微服务，那么至少有10个 配置文件吧，三个环境（dev\test\prod），那就有30个配置文 件需要进行管理。
概念
用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同 环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如 配置、服务）隔离等。默认namespace=public的保留空间,不支持删除;默认情况下。
场景
Nacos给的最佳实践表明，最外层的namespace是可以用于区分部署环境的，比如test，dev，prod等。
注意： 命名空间可用于进行不同环境的配置隔离。一般一个环境划分到一个命名空间。
新建dev/test的Namespac
查看命名空间
实时效果反馈
1.Nacos组件Namespace命名空间主要作用_____。
A 多环境下的配置隔离和管理
B 组织划分配置
C 组织配置
D 以上都是错误
2. Nacos组件中Namespace是可以用于区分____。
A 项目配置
B 配置文件
C 部署环境
D 以上都是错误
分布式配置中心_DataID配置
概念
Nacos 中的某个配置集的 ID，配置集 ID 是组织划分配置的维度之 一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用 可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。
注意： 在系统中，一个配置文件通常就是一个配置集。一般微服务的配置就是一个配置集。
dataId的拼接格式
解释：
1、prefix：默认为 spring.application.name 的值。
2、spring.profiles.active：即为当前环境对应的 profile。
3、file-extension：文件后缀
当activeprofile为空时。
新建dev配置DataID
编写配置
实时效果反馈
1.Nacos组件dataId中prefix所表示的含义__。
A 应用名字
B 环境
C 后缀名
D 以上都是错误
2. Nacos组件dataId中file-extension所表示的含义__。
A 应用名字
B 环境
C 后缀名
D 以上都是错误
分布式配置中心_Group分组方案
概念
Nacos中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串对配置集进行分组，从而区分Data ID相同的配置集。当您在 Nacos上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用DEFAULT_GROUP 。
通过Group实现环境区分
在Nacos图形界面控制台上传新建配置文件DataID
实时效果反馈
1.Nacos组件中Group默认分组名字是_____。
A DEFAULT
B GROUP
C DEFAULT_GROUP
D 以上都是错误
分布式配置中心_Namespace实施方案
Nacos给出了两种Namespace的实践方案
1、面向一个租户
2、面向多个租户
面向一个租户
从一个租户(用户)的角度来看，如果有多套不同的环境，那么这个时候可以根据指定的环境来创建不同的 namespce，以此来实现多环境的隔离。
例如，你可能有dev，test和prod三个不同的环境，那么使用一套 nacos 集群可以分别建以下三个不同的namespace。
问题： 这里的单租户同样也适于小型项目，或者是项目不太多时的实施方案，通过定义不同的环境，不同环境的项目在不同的 Namespace下进行管理，不同环境之间通过Namespace进行隔离。
面向多个租户
当多个项目同时使用该Nacos集群时，还可以通过Group进行 Namespace内的细化分组。这里以 Namespace：dev 为例，在 Namespace中通过不同Group进行同一环境中不同项目的再分类 。
注意： 通过上面的理论分析，可以看出方案二有很好的扩展性
实时效果反馈
1.Nacos技术中Namespace命名空间面向一个租户适用_____。
A 小型项目
B 中型项目
C 大型项目
D 以上都是错误
2.Nacos技术中Namespace命最佳实施方案_____有很好的扩展性。
A 面向单个租户
B 面向一个租户
C 面向多个租户
D 以上都是错误
分布式配置中心_将应用对接Nacos配置中心
新建配置
创建工程cloud-nacos-config3344
POM引入依赖
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>
</dependencies>
编写主启动类
/**
* 主启动类
*/
@SpringBootApplication
@Slf4j
@EnableDiscoveryClient
public class NacosConfigMain3344 {
public static void main(String[] args) {
SpringApplication.run(NacosConfigMain3344.class,args);
log.info("***********NacosConfigMain3344 **********");
}
}创建配置文件
创建配置文件名为 bootstrap.yml ,注意是bootstrap.yml，而不是 application 。
原因： Nacos同SpringCloud-Config一样，在项目初始化时，要保证先从配置中心进行配置拉取，拉取配置之后，才能保证项目的正常启动。SpringBoot中配置文件的加载是存在优先级顺序的， bootstrap优先级高于application。
server:
port: 3344
spring:
application:
name: nacos-config
cloud:
nacos:
discovery:
server-addr: 192.168.66.101:8848
config:
#服务器地址
server-addr: 192.168.66.101:8848
#默认为Public命名空间,可以省略不写 #对应建立的命名空间的UUID
namespace: a26e7bb2-04df-4574-8313-3d8728ae88ba
#指定文件后缀
file-extension: yaml
#文件名 -- 如果没有配置则默认为 ${spring.appliction.name}
prefix: ${spring.application.name}
#指定配置群组 --如果是Public命名空间 则可以省略群组配置
group: DEFAULT_GROUP
profiles:
active: dev 
上面的配置是为了保证服务的正常注册和配置获取，以及配置 DataID 的正确性
创建对外接口来从nacos中读取配置
@RestController
public class NacosConfigController {
@Value("${nacos.config}")
private String config;
@RequestMapping("/getValue")
public String getValue() {
return config;
}出现问题
出现报错，肯定配置写错了，检查5步曲
具体细节看下图
测试 请求http://localhost:3344/getValue
