springcloud nacos配置redis集群 springcloud集成nacos

目录

1. 注册服务到Nacos

1.1 引入依赖

1.2 配置Nacos地址

2. 服务分级存储模型 

2.1 给user-service配置集群

2.2 同集群优先的负载均衡

3. 权重配置

4. 环境隔离 

5. Nacos与Eureka的区别

6. Nacos配置管理

6.1 统一配置管理

  6.1.1 在nacos中添加配置文件

6.1.2 从微服务拉取配置

6.2 配置热更新

Nacos和Eureka一样，也是微服务中的注册中心。

1. 注册服务到Nacos

1.1 引入依赖

在父工程pom文件<dependencyManagement> 中引入

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

在子工程中引入nacos-discovery依赖：

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

1.2 配置Nacos地址

 application.yml中添加nacos地址：

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

2. 服务分级存储模型 

一个服务有多个实例，Nacos将同一机房内的实例划分为一个集群。

换句话说就是一个服务有多个集群，一个集群包含多个实例。

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

2.1 给user-service配置集群

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

2.2 同集群优先的负载均衡

 默认的ZoneAvoidanceRule并不能实现根据同集群优先来实现负载均衡。因此Nacos中提供了一个NacosRule的实现，可以优先从同集群中挑选实例。

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

3. 权重配置

在nacos控制台点击编辑可以修改权重。0-1

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

4. 环境隔离 

Nacos提供了namespace来实现环境隔离功能。

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

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

自己想要新建的话对应Nacos控制台的命名空间。

可以修改yml文件来给服务配置namespace：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ
        namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间，填ID

5. Nacos与Eureka的区别

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

• 临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。
• 非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

在yml中的配置

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

Nacos与eureka的共同点

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

Nacos与Eureka的区别

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

扩展：

CAP理论提出就是针对分布式数据库环境的，所以，P这个属性是必须具备的。
P就是在分布式环境中，由于网络的问题可能导致某个节点和其它节点失去联系，这时候就形成了P(partition)，也就是由于网络问题，将系统的成员隔离成了2个区域，互相无法知道对方的状态，这在分布式环境下是非常常见的。
因为P是必须的，那么我们需要选择的就是A和C。
大家知道，在分布式环境下，为了保证系统可用性，通常都采取了复制的方式，避免一个节点损坏，导致系统不可用。那么就出现了每个节点上的数据出现了很多个副本的情况，而数据从一个节点复制到另外的节点时需要时间和要求网络畅通的，所以，当P发生时，也就是无法向某个节点复制数据时，这时候你有两个选择：
选择可用性 A(Availability)，此时，那个失去联系的节点依然可以向系统提供服务，不过它的数据就不能保证是同步的了（失去了C属性）。

选择一致性C(Consistency)，为了保证数据库的一致性，我们必须等待失去联系的节点恢复过来，在这个过程中，那个节点是不允许对外提供服务的，这时候系统处于不可用状态(失去了A属性)。

最常见的例子是读写分离，某个节点负责写入数据，然后将数据同步到其它节点，其它节点提供读取的服务，当两个节点出现通信问题时，你就面临着选择A（继续提供服务，但是数据不保证准确），C（用户处于等待状态，一直等到数据同步完成）。

6. Nacos配置管理

6.1 统一配置管理

  6.1.1 在nacos中添加配置文件

填写配置信息：

注意：项目的核心配置，需要热更新的配置才有放到nacos管理的必要。基本不会变更的一些配置还是保存在微服务本地比较好。

6.1.2 从微服务拉取配置

spring引入了一种新的配置文件：bootstrap.yaml文件，会在application.yml之前被读取，流程如下：

 首先，在user-service服务中，引入nacos-config的客户端依赖：

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

添加bootstrap.yaml

 

 读取nacos配置  

6.2 配置热更新

两种方式：

• 在@Value注入的变量所在类上添加注解@RefreshScope：
• 使用@ConfigurationProperties注解代替@Value注解。在user-service服务中，添加一个类，读取patterrn.dateformat属性：

package cn.itcast.user.config;

import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

@Component
@Data
@ConfigurationProperties(prefix = "pattern")
public class PatternProperties {
    private String dateformat;
}

在UserController中使用这个类代替@Value：