day01-springcloud-nacos

SpringCloud01

01概述导入：

1. 单体项目-》分布式项目 (微服务)

02.我们今天学习目标：

1. 单体项目-》分布式项目 (微服务)
2. 众多微服务如何管理、相互调用的
   1. 注册中心-Eureka和Nacos
   2. Eureka和Nacos对比

1.认识微服务

随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构。这些架构之间有怎样的差别呢？

1.1.单体架构

单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。

单体架构的优缺点如下：

优点：

• 架构简单
• 部署成本低

缺点：

• 耦合度高（维护困难、升级困难）

1.2.分布式架构

分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。

分布式架构的优缺点：

优点：

• 降低服务耦合
• 有利于服务升级和拓展
• 有利于团队分工协作开发

缺点：

• 服务调用关系错综复杂

分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：

• 服务拆分的粒度如何界定？
• 服务之间如何调用？
• 服务的调用关系如何管理？

人们需要制定一套行之有效的标准来约束分布式架构。

1.3.微服务

微服务的架构特征：

• 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责。 报表-帆软 数据采集 流程
• 自治：团队独立、技术独立、数据独立，独立部署和交付
• 面向服务：服务提供统一标准的接口，与语言和技术无关
• 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。

因此，可以认为微服务是一种经过良好架构设计的分布式架构方案 。

但方案该怎么落地？选用什么样的技术栈？全球的互联网公司都在积极尝试自己的微服务落地方案。

其中在Java领域最引人注目的就是SpringCloud提供的方案了。

spring cloud Tencent

面试题

• 单体架构和微服务架构区别？微服务架构你有什么搭建策略？

• 单体架构：一个项目干所有的事

  • 优点：简单、
  • 缺点：耦合高、并发低、团队开发困难、发布慢…

• 微服务

  • 一套分布式解决方案
    • 优点：耦合低、并发高、敏捷开发、单一部署
    • 缺点：服务复杂、难！

• 搭建思路：

  • 单一职责：一个服务一个库
  • 自治：独立自治
  • 暴露接口
  • 隔离

1.4.SpringCloud

SpringCloud是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud。

SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验。

其中常见的组件包括：

另外，SpringCloud底层是依赖于SpringBoot的，并且有版本的兼容关系，如下：

我们课堂学习的版本是 Hoxton.SR10，因此对应的SpringBoot版本是2.3.x版本。

1.5.总结

• 单体架构：简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统

• 分布式架构：松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝

• 微服务：一种良好的分布式架构方案

  ①优点：拆分粒度更小、服务更独立、耦合度更低

  ②缺点：架构非常复杂，运维、监控、部署难度提高

• SpringCloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件

2.服务拆分和远程调用

2.1.服务拆分原则

这里我总结了微服务拆分时的几个原则：（重要）

• 不同微服务，不要重复开发相同业务
• 微服务数据独立，不要访问其它微服务的数据库
• 微服务可以将自己的业务暴露为接口，供其它微服务调用

2.2.服务拆分示例

以课前资料中的微服务cloud-demo为例，其结构如下：

cloud-demo：父工程，管理依赖

• order-service：订单微服务，负责订单相关业务
• user-service：用户微服务，负责用户相关业务

要求：

• 订单微服务和用户微服务都必须有各自的数据库，相互独立
• 订单服务和用户服务都对外暴露Restful的接口
• 订单服务如果需要查询用户信息，只能调用用户服务的Restful接口，不能查询用户数据库

2.2.1.导入Sql语句

首先，将课前资料提供的cloud-order.sql和cloud-user.sql导入到mysql中：

cloud-user表中初始数据如下：

cloud-order表中初始数据如下：

cloud-order表中持有cloud-user表中的id字段。

2.2.2.导入demo工程

用IDEA导入课前资料提供的Demo：

项目结构如下：

导入后，会在IDEA右下角出现弹窗：

点击弹窗，然后按下图选择：

会出现这样的菜单：

配置下项目使用的JDK：

2.3.实现远程调用案例

在order-service服务中，有一个根据id查询订单的接口：

根据id查询订单，返回值是Order对象，如图：

其中的user为null

在user-service中有一个根据id查询用户的接口：

查询的结果如图：

2.3.1.案例需求：

修改order-service中的根据id查询订单业务，要求在查询订单的同时，根据订单中包含的userId查询出用户信息，一起返回。

因此，我们需要在order-service中 向user-service发起一个http的请求，调用http://localhost:8081/user/{userId}这个接口。

大概的步骤是这样的：

• 注册一个RestTemplate的实例到Spring容器
• 修改order-service服务中的OrderService类中的queryOrderById方法，根据Order对象中的userId查询User
• 将查询的User填充到Order对象，一起返回

2.3.2.注册RestTemplate

RestTemplate 简介

RestTemplate 是从 Spring3.0 开始支持的一个 HTTP 请求工具，它提供了常见的REST请求方案的模版，例如 GET 请求、POST 请求、PUT 请求、DELETE 请求以及一些通用的请求执行方法 exchange 以及 execute。RestTemplate 继承自 InterceptingHttpAccessor 并且实现了 RestOperations 接口，其中 RestOperations 接口定义了基本的 RESTful 操作，这些操作在 RestTemplate 中都得到了实现。接下来我们就来看看这些操作方法的使用。

首先，我们在order-service服务中的OrderApplication启动类中，注册RestTemplate实例：

package com.itgaohe.order;
import org.mybatis.spring.annotation.MapperScan;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;

@MapperScan("com.itgaohe.order.mapper")
@SpringBootApplication
public class OrderApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

2.3.3.实现远程调用

修改order-service服务中的com.itgaohe.order.service包下的OrderService类中的queryOrderById方法：

@Service
public class OrderService {
    @Autowired
    private OrderMapper orderMapper;
    @Autowired
    private RestTemplate restTemplate;

   public Order queryOrderByUserId(Long orderId) {
        // 根据id查询订单并返回
        Order order = orderService.queryOrderById(orderId);
        /*定义地址*/
        String url = "http://localhost:8081/user/1";
        /*远程调用查询*/
        User user = restTemplate.getForObject(url, User.class);
        /*赋值*/
        order.setUser(user);
        return order;
    }
}

2.4.提供者与消费者

在服务调用关系中，会有两个不同的角色：

服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）

服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）

但是，服务提供者与服务消费者的角色并不是绝对的，而是相对于业务而言。

如果服务A调用了服务B，而服务B又调用了服务C，服务B的角色是什么？

• 对于A调用B的业务而言：A是服务消费者，B是服务提供者
• 对于B调用C的业务而言：B是服务消费者，C是服务提供者

因此，服务B既可以是服务提供者，也可以是服务消费者。

3.Nacos注册中心

服务调用出现的问题

1.服务消费者该如何获取服务提供者的地址信息？

2.如果有多个服务提供者，消费者该如何选择？

3.消费者如何得知服务提供者的健康状态？

3.0 注册中心选型

nacos和eureka对比

nacos	eureka
服务注册和服务拉取
都支持服务提供者心跳方式做健康检测
临时实例采用心跳模式，非临时实例采用主动检测模式	不支持
支持服务列表变更的消息推送模式，服务列表更新更及时	不支持
Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式	Eureka采用AP方式
注册中心	不支持

3.1Nacos与Eureka的区别

Nacos的服务实例分为两种l类型：

• 临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。

• 非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

配置一个服务实例为永久实例：

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例

• Nacos与eureka的共同点

  • 都支持服务注册和服务拉取
  • 都支持服务提供者心跳方式做健康检测

• Nacos与Eureka的区别

  • Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
  • 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
  • Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
  • Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

CAP理论

这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
一致性©：在分布式系统中，如果服务器集群，每个节点在同时刻访问必须要保持数据的一致性。
可用性(A)：集群节点中，部分节点出现故障后任然可以使用 （高可用）
分区容错性§：在分布式系统中网络会存在脑裂的问题，部分Server与整个集群失去节点联系，无法组成一个群体。

CP与AP的选择

CP：我们服务可以不能用，但必须要保证数据的一致性。
AP:数据可以短暂不一致，但最终是需要一致的，无论如何都要保证服务的可用。
只取舍：有在CP和AP选择一个平衡点，大多数都是选择AP模式。

3.2.认识和安装Nacos

• 启动
• 注册
• 发现
• 配置中心

国内公司一般都推崇阿里巴巴的技术，比如注册中心，SpringCloudAlibaba也推出了一个名为Nacos的注册中心。

Nacos是阿里巴巴的产品，现在是SpringCloud中的一个组件。相比Eureka功能更加丰富，在国内受欢迎程度较高。

安装方式可以参考课前资料《Nacos安装指南.md》

#windows启动命令：
startup.cmd -m standalone

3.3.服务注册到nacos

Nacos是SpringCloudAlibaba的组件，而SpringCloudAlibaba也遵循SpringCloud中定义的服务注册、服务发现规范。因此使用Nacos和使用Eureka对于微服务来说，并没有太大区别。

主要差异在于：

• 依赖不同
• 服务地址不同

1）引入依赖

在cloud-demo父工程的pom文件中的<dependencyManagement>中引入SpringCloudAlibaba的依赖：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.6.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

然后在user-service和order-service中的pom文件中引入nacos-discovery依赖：

<!--引入nacos 注册中心依赖-->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>
     

2）配置nacos地址

在user-service和order-service的application.yml中添加nacos地址：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848

3）重启

重启命令
startup.cmd -m standalone
访问地址
http://127.0.0.1:8848/nacos

重启微服务后，登录nacos管理页面，可以看到微服务信息：

3.4 服务拉取和负载均衡

我们要去nacos中拉取user-service服务的实例列表，并且实现负载均衡。

不过这些动作不用我们去做，只需要添加一些注解即可。

在order-service的OrderApplication中，给RestTemplate这个Bean添加一个@LoadBalanced注解：

服务负载均衡默认轮询

3.5 Nacos服务发现-服务发现

修改order-service服务中的com.itgaohe.order.service包下的OrderService类中的queryOrderById方法。修改访问的url路径，用服务名代替ip、端口：

spring会自动帮助我们从user-server端，根据userservice这个服务名称，获取实例列表，而后完成负载均衡。

3.6 Nacos服务发现-负载测试

服务负载均衡

使用nacos实现负载均衡修改端口后再启动一个服务。 访问order服务 多次刷新看控制台数据数据。

3.7 Nacos服务发现-日志配置

服务日志配置

# 日志配置
logging:
  level:
    com.itgaohe: debug
  pattern:
    dateformat: MM-dd HH:mm:ss:SSS

3.8 Nacos服务发现-心跳机制

Nacos和Eureka整体结构类似，服务注册、服务拉取、心跳等待，但是也存在一些差异：

所有服务都被nacos管理

1. 服务请求发送的时候 先去nacos中拉取服务列表
2. push下来的数据做负载
3. 每隔30s nacos注册中心 主动询问服务提供者 服务提供者通过心跳监测回应注册中心。

临时实例和非临时实例
服务注册到Nacos时，可以选择注册为临时或非临时实例，通过下面的配置来设置：
临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型
非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例
Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例

Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）

3.9.Nacos注册中心-集群

3.9.1Nacos服务分级存储模型

多地集群性能提升方案

一个服务可以有多个实例，例如我们的user-service，可以有:

• 127.0.0.1:8081
• 127.0.0.1:8082
• 127.0.0.1:8083

假如这些实例分布于全国各地的不同机房，例如：

• 127.0.0.1:8081，在上海机房
• 127.0.0.1:8082，在上海机房
• 127.0.0.1:8083，在杭州机房

Nacos就将同一机房内的实例 划分为一个集群。

也就是说，user-service是服务，一个服务可以包含多个集群，如杭州、上海，每个集群下可以有多个实例，形成分级模型，如图：

3.9.2 服务跨集群调用问题

微服务互相访问时，应该尽可能访问同集群实例，因为本地访问速度更快。当本集群内不可用时，才访问其它集群。例如：

tips:但是我们配置完成并不会有效，依然是轮询，我们还需要修改负载均衡方式

济南机房内的order-service应该优先访问同机房的user-service。

3.9.3.Nacos注册中心-集群配置

服务集群属性

给user-service配置集群

修改user-service的application.yml文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848 # nacos 服务端地址
      discovery:
        cluster-name: jinan # 配置集群名称，也就是机房位置，例如：jinan

重启两个user-service实例后，我们可以在nacos控制台看到下面结果：

点击nacos 中的详情页面

tips:  bean配置优先级高于yml配置优先级

我们再次复制一个user-service启动配置，添加属性：

-Dserver.port=8084 -Dspring.cloud.nacos.discovery.cluster-name=beijing

配置如图所示：

启动UserApplication3后再次查看nacos控制台：

4.Ribbon负载均衡

上一节中，我们添加了@LoadBalanced注解，即可实现负载均衡功能，这是什么原理呢？

轮询、权重、随机。。。

4.1.负载均衡策略

4.1.1.负载均衡策略

负载均衡的规则都定义在IRule接口中，而IRule有很多不同的实现类：

不同规则的含义如下：

内置负载均衡规则类	规则描述
RoundRobinRule	简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。
AvailabilityFilteringRule	对以下两种服务器进行忽略： （1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。 （2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的..ActiveConnectionsLimit属性进行配置。
WeightedResponseTimeRule	为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。
ZoneAvoidanceRule	以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。
BestAvailableRule	忽略那些短路的服务器，并选择并发数较低的服务器。
RandomRule	随机选择一个可用的服务器。
RetryRule	重试机制的选择逻辑

默认的实现就是ZoneAvoidanceRule，是一种轮询方案

4.1.2.自定义负载均衡策略

通过定义IRule实现可以修改负载均衡规则，有两种方式：

1. 代码方式：在order-service中的OrderApplication类中，定义一个新的IRule：

@Bean
public IRule randomRule(){
    return new RandomRule();
}

2. 配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：

user-service: # 给某个微服务配置负载均衡规则，这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.ZoneAvoidanceRule  # 负载均衡规则 RandomRule 随机选择 

tips:  bean配置优先级高于yml配置优先级

注意，一般用默认的负载均衡规则，不做修改。

4.1.3.同集群优先的负载均衡

默认的ZoneAvoidanceRule并不能实现根据同集群优先来实现负载均衡。

因此Nacos中提供了一个NacosRule的实现，可以优先从同集群中挑选实例。

1）给order-service配置集群信息

修改order-service的application.yml文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: jinan # 集群名称

2）修改负载均衡规则

修改order-service的application.yml文件，修改负载均衡规则：

user-service:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则 

4.2.饥饿加载

演示 刷新页面 第一次加载时间长 后面都会变快。

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。

而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

order-service

ribbon:
  eager-load:
    enabled: true
    clients: user-service

4.3.Nacos权重负载均衡

实际部署中会出现这样的场景：

服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。

但默认情况下NacosRule是同集群内随机挑选，不会考虑机器的性能问题。

因此，Nacos提供了重配置来控制访问频率，权重越大则访问频率越高。

在nacos控制台，找到user-service的实例列表，点击编辑，即可修改权重：

在弹出的编辑窗口，修改权重：

**注意：如果权重修改为0，则该实例永远不会被访问

4.4.负载均衡原理

负载均衡流程

SpringCloud底层其实是利用了一个名为Ribbon的组件，来实现负载均衡功能的。

我们发出的请求明明是http://userservice/user/1，怎么变成了http://localhost:8081的呢？

4.5.源码跟踪

为什么我们只输入了service名称就可以访问了呢？之前还要获取ip和端口。

显然有人帮我们根据service名称，获取到了服务实例的ip和端口。它就是LoadBalancerInterceptor，这个类会在对RestTemplate的请求进行拦截，然后从Eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。

我们进行源码跟踪：

1.LoadBalancerInterceptor

找个这个类

向下执行一行

可以看到这里的intercept方法，拦截了用户的HttpRequest请求，然后做了几件事：

• request.getURI()：获取请求uri，本例中就是 http://user-service/user/1
• originalUri.getHost()：获取uri路径的主机名，其实就是服务id，user-service
• this.loadBalancer.execute()：处理服务id，和用户请求。

这里的this.loadBalancer是LoadBalancerClient类型，我们继续跟入。

2.RibbonLoadBalancerClient

继续跟入execute方法：

代码是这样的：

• getLoadBalancer(serviceId)：根据服务id获取ILoadBalancer，而ILoadBalancer会拿着服务id去nacos中获取服务列表并保存起来。
• getServer(loadBalancer)：利用内置的负载均衡算法，从服务列表中选择一个。本例中，可以看到获取了8082端口的服务

放行后，再次访问并跟踪，发现获取的是8081：

果然实现了负载均衡。

3.负载均衡策略IRule

ctrl+H

在刚才的代码中，可以看到获取服务使通过一个getServer方法来做负载均衡:

我们继续跟入：

继续跟踪源码chooseServer方法，发现这么一段代码：

进入到choose方法 我们看看这个rule是谁：

全局搜索 DEFAULT_RULE

我们发现 rule对象 == DEFAULT_RULE

这里的rule默认值是一个RoundRobinRule，看类的介绍：

这不就是轮询的意思嘛。

到这里，整个负载均衡的流程我们就清楚了。

4.总结

SpringCloudRibbon的底层采用了一个拦截器，拦截了RestTemplate发出的请求，对地址做了修改。用一幅图来总结一下：

基本流程如下：

• 拦截我们的RestTemplate请求http://userservice/user/1

• RibbonLoadBalancerClient会从请求url中获取服务名称，也就是user-service

• DynamicServerListLoadBalancer根据user-service到eureka拉取服务列表

• eureka返回列表，localhost:8081、localhost:8082

• IRule利用内置负载均衡规则，从列表中选择一个，例如localhost:8081

• RibbonLoadBalancerClient修改请求地址，用localhost:8081替代userservice，

  得到http://localhost:8081/user/1，发起真实请求

4.6 总结

Ribbon:

• ​ @LoadBalanced 默认是轮询方式
• 自定义：

userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

• 负载均衡服务加载方式：默认是懒加载

ribbon:
  eager-load:
    enabled: true
    clients: userservice

懒加载：

• 线程池
• servlet
• beanFactory
• ribbon

饿加载：

• springboot加载我们自定义代码

5.Nacos环境隔离

Nacos中可以跑多个项目 多个项目之间需要隔离。

Nacos提供了namespace来实现环境隔离功能,用来做最外层隔离(隔离访问和配置中心)

• nacos中可以有多个namespace
• namespace下可以有group、service等
• 不同namespace之间相互隔离，例如不同namespace的服务互相不可见

5.1.创建namespace

默认情况下，所有service、data、group都在同一个namespace，名为public：

我们可以点击页面新增按钮，添加一个namespace：

然后，填写表单：

就能在页面看到一个新的namespace：

5.2.给微服务配置namespace

给微服务配置namespace只能通过修改配置来实现。

例如，修改user-service的application.yml文件：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: jinan
        namespace: dac36cb1-71fa-4658-b7bb-130470cdd136 # 命名空间，填ID

重启北京的user-service后 ，访问控制台，可以发现能正常访问；但是不会进入到北京的user-service中，关闭其他user-service 服务 再次刷新进入页面，发现报错500；

此时访问order-service，因为namespace不同，会导致找不到userservice，控制台会报错：

5.3 总结

Nacos环境隔离
1.每个namespace都有唯一id
2.服务设置namespace时要写id而不是名称
3.不同namespace下的服务互相不可见

6.Nacos配置管理

统一配置管理
配置热更新
配置共享
搭建Nacos集群

6.1 统一配置管理

6.1.1 nacos配置文件

在nacos配置列表中 配置配置文件

文件名遵循命名规则 :

服务名称-开发环境.yaml

6.1.2 java服务导入

引入Nacos的配置管理客户端依赖：

<!--nacos配置管理依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

在userserver中的resource目录添加一个bootstrap.yml文件，这个文件是引导文件，优先级高于application.yml：

引导文件 引导yml优先加载 nacos中的配置

spring:
  application:
    name: user-service # 服务名称
  profiles:
    active: dev #开发环境，这里是dev 对应文件名
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
      config:
        file-extension: yaml # 文件后缀名

UserController

 @Value("${user.data}")
    private String data;
    @GetMapping
    public String dataString(){
        System.out.println(data);
        return "远程数据:"+data;
    }

测试：

访问 http://localhost:8081/user

6.1.3 统一配置管理原理

配置获取的步骤如下：

6.2 Nacos配置管理-热部署

配置自动刷新

Nacos中的配置文件变更后，微服务无需重启就可以感知。不过需要通过下面两种配置实现：

6.2.1 方式一

方式一：在@Value注入的变量所在类上添加注解@RefreshScope

修改nacos中的配置文件 访问端口 看数据在不重启服务前提下是否会更新。

6.2.1 方式二

方式二：使用@ConfigurationProperties注解

1.创建DataParam

import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;
@ConfigurationProperties(prefix = "user")
@Component
@Data
public class DataParam {
    private String data;
}

2.UserController

@Autowired
private DataParam dataParam;
@Value("${user.data}")
private String data;
@GetMapping
public String dataString(){
    System.out.println(data);
    return "远程数据:"+data + "dataParam:" + dataParam;
}

3.测试

注释掉 //@RefreshScope

重复方式一进行测试。

6.2.3 总结

微服务热更新，方式：

通过@Value注解注入，结合@RefreshScope来刷新

通过@ConfigurationProperties注入，自动刷新

注意事项：

不是所有的配置都适合放到配置中心，维护起来比较麻烦

建议将一些关键参数，需要运行时调整的参数放到nacos配置中心，一般都是自定义配置

6.3 配置共享

微服务启动时会从nacos读取多个配置文件：

[spring.application.name]-[spring.profiles.active].yaml，例如：userserver-dev.yaml

[spring.application.name].yaml，例如：userserver.yaml

无论profile如何变化，[spring.application.name].yaml这个文件一定会加载，因此多环境共享配置

可以写入这个文件

1.创建nacos公共文件

2.添加yml配置

shared-configs指定:共享的配置文件id

spring:
  application:
    name: user-service # 服务名称
  profiles:
    active: dev # 环境
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
      config: 
        file-extension: yaml # 文件后缀名
        shared-configs: # 多微服务间共享的配置列表
          - dataId: common.yaml # 要共享的配置文件id

UserController

 @Autowired
    private DataParam dataParam;
    @Value("${user.data}")
    private String data;
    @Value("${common.data}")
    private String commonData;
    @GetMapping
    public String dataString(){
        System.out.println(data);
        return "远程数据:"+data + "dataParam:" + dataParam+"---"+commonData;
    }

6.4 配置的优先级

多服务共享配置

多种配置的优先级：服务名-profile.yaml >服务名称.yaml > shared-config > 本地配置

6.5.总结

外面优先级》里边的（后边的覆盖前面）

细粒度覆盖粗粒度

1. 配置管理步骤：

   1. 远程写一个配置文件
   2. 本地引入bootstrap配置文件，和远程配置文件关联
   3. 写配置类实现热部署

2. 配置共享的优先级

   

面试题：

• springboot配置文件你知道哪几种？他们的同配置生效顺序是什么？

  项目外配置文件（nacos配置文件）>aplication-dev.properties >application.properties 
  aplication.yaml >aplication.yml>bootstrap.yaml
  
  为什么bootstrap.yaml最后生效呢？
  bootstrap.yml 由父Spring ApplicationContext加载,承接上下文。
  bootstrap.yml 可以理解成系统级别的一些参数配置，这些参数一般是不会变动的。
  由里向外加载，所以最外层的最后被加载，会覆盖里层的属性
  
  外面优先级》里边的（后边的覆盖前面）
  细粒度覆盖粗粒度
  

• 哪个配置文件可以实现热部署或云配置？ bootstrap.yaml

• 热部署配置文件的生效顺序是什么？

  • tips: 云userserver-dev.yaml 云userserver.yaml 本地application.yaml

• 热部署同步实现方式有几种，分别是什么？

  • 2种： @RefreshScope @ConfigurationProperties(prefix = “pattern”)

今日总结：

微服务和单体有什么区别？微服务拆分？微服务之间调用的？

• 单体项目 —》微服务 （能够口述）
  • 降低服务耦合
  • 有利于服务升级和拓展
  • 有利于团队分工协作开发
• 微服务拆分（能够理解）
  • 不同微服务，不要重复开发相同业务、单一职责（一个服务一个库）
  • 自治（团队管理）
  • 微服务可以将自己的业务暴露为接口，供其它微服务调用
  • 隔离性
• 远程调用：RestTemplate对象 （能够使用）
• Eureka注册中心 （能够操作）
  • 服务搭建
  • 服务注册（重点）
  • 服务发现（重点）
  • 负载均衡 （重点）
• nacos （能够操作）
  • 服务启动
  • 服务注册**（重点）**
  • 服务发现**（重点）**
  • 服务分级 负载均衡 权重 环境隔离 test dev pro
  • 热部署（重要）
• Eureka 和nacos对比（了解）====> nacos 完胜！！
  • Nacos与eureka的共同点
    • 都支持服务注册和服务拉取
    • 都支持服务提供者心跳方式做健康检测
  • Nacos与Eureka的区别
    • Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
    • 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
    • Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
    • Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

bootstrap.yaml

为什么bootstrap.yaml最后生效呢？
bootstrap.yml 由父Spring ApplicationContext加载,承接上下文。
bootstrap.yml 可以理解成系统级别的一些参数配置，这些参数一般是不会变动的。
由里向外加载，所以最外层的最后被加载，会覆盖里层的属性

外面优先级》里边的（后边的覆盖前面）
细粒度覆盖粗粒度

- 哪个配置文件可以实现热部署或云配置？ bootstrap.yaml

- 热部署配置文件的生效顺序是什么？

- tips: 云userserver-dev.yaml     云userserver.yaml   本地application.yaml

- 热部署同步实现方式有几种，分别是什么？

- 2种：   @RefreshScope    @ConfigurationProperties(prefix = "pattern")