Nacos(注册中心)

Nacos服务管理

1.1 简介：

1.1.1 服务发现产品对比

目前市面上用的比较多的服务发现中心有：Nacos、Eureka、Consul和Zookeeper。

分布式中的cap理论：CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

         从上面对比可以了解到，Nacos作为服务发现中心，具备更多的功能支持项，且从长远来看Nacos在以后的版本会支持SpringCloud+Kubernetes的组合，填补2者的鸿沟，在两套体系下可以采用同一套服务发现和配置管理的解决方案，这将大大的简化使用和维护的成本。另外，Nacos 计划实现 Service Mesh，也是未来微服务发展的趋势。

1.1.2 Nacos简介

        Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。 Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Nacos 是构建以“服务”为中心的现代应用架构的服务基础设施。

官网地址：https://nacos.io

1.1.3 Nacos特性

1. 服务发现与服务健康检查

   Nacos使服务更容易注册，并通过DNS或HTTP接口发现其他服务，Nacos还提供服务的实时健康检查，以防止向不健康的主机或服务实例发送请求。

2. 动态配置管理

   动态配置服务允许您在所有环境中以集中和动态的方式管理所有服务的配置。Nacos消除了在更新配置时重新部署应用程序，这使配置的更改更加高效和灵活。

3. 动态DNS服务

   动态配置服务允许您在所有环境中以集中和动态的方式管理所有服务的配置。Nacos消除了在更新配置时重新部署应用程序，这使配置的更改更加高效和灵活。

4. 服务和元数据管理

   Nacos能让您从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略。

1.2 安装Nacos Server

1.2.1 环境准备

Nacos 依赖 Java 环境来运行。如果您是从代码开始构建并运行Nacos，还需要为此配置 Maven环境，请确保是在以下版本环境中安装使用:

1. 64 bit OS，支持 Linux/Unix/Mac/Windows，推荐选用 Linux/Unix/Mac。

2. 64 bit JDK 1.8+；下载 & 配置。

3. Maven 3.2.x+；下载 & 配置。

1.2.2 下载源码和安装包

git clone https://github.com/alibaba/nacos.git cd nacos/
mvn  -Prelease-nacos  clean  install  -U ls -al distribution/target/
// change the $version to your actual path
cd distribution/target/nacos-server-$version/nacos/bin
你可以通过源码和发行包两种方式来获取 Nacos。**从** **Github** **上下载源码方式

1.2.3 启动服务

        nacos的默认端口是8848，需要保证8848默认端口没有被其他进程占用。进入安装程序的bin目录：

Windows启动方式： 启动命令：

cmd startup.cmd或者双击startup.cmd运行文件。

启动成功，可通过浏览器访问 http://127.0.0.1:8848/nacos 。

使用默认用户名：nacos，默认密码：nacos 登录即可打开主页面。

1.3 RESTful服务发现

1.3.1 测试环境

Spring Cloud是一套微服务开发框架集合，包括微服务开发的方方页面，Spring Cloud还是一套微服务开发的标准， 集成了很多优秀的开源框架，比如有名的Netflix公司的众多项目。

Spring Cloud Netflix包含的组件及其主要功能大致如下：

Eureka，服务注册和发现，它提供了一个服务注册中心、服务发现的客户端，还有一个方便的查看所有注册的服务的界面。 所有的服务使用Eureka的服务发现客户端来将自己注册到Eureka的服务器上。

Zuul，网关，所有的客户端请求通过这个网关访问后台的服务。他可以使用一定的路由配置来判断某一个URL由哪个服务来处理。并从Eureka获取注册的服务来转发请求。

Ribbon，即负载均衡，Zuul网关将一个请求发送给某一个服务的应用的时候，如果一个服务启动了多个实例，就会通过Ribbon来通过一定的负载均衡策略来发送给某一个服务实例。

Feign，服务客户端，服务之间如果需要相互访问，可以使用RestTemplate，也可以使用Feign客户端访问。它默认会使用Ribbon来实现负载均衡。

Hystrix，监控和熔断器。我们只需要在服务接口上添加Hystrix标签，就可以实现对这个接口的监控和断路器功能。

Hystrix Dashboard，监控面板，他提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。

Turbine，监控聚合，使用Hystrix监控，我们需要打开每一个服务实例的监控信息来查看。而Turbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。这样就不需要挨个打开一个个的页面一个个查看。

Spring Cloud 项目地址：Spring Cloud

本测试环境采用阿里开源的Spring Cloud Alibaba微服务开发框架，Spring Cloud Alibaba是阿里巴巴公司基于Spring Cloud标准实现一套微服务开发框架集合，它和Netflix一样都是Spring Cloud微服务开发实现方案。

Spring Cloud Alibaba项目地址：https://github.com/alibaba/spring-cloud-alibaba

通过Spring Cloud Alibaba实现解决：

1、服务发现客户端从服务发现中心获取服务列表

2、服务消费方通过负载均衡获取服务地址在nacos-discovery父工程中添加依赖管理

<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>2.1.3.RELEASE</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>Greenwich.RELEASE</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <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>

3、分别在服务提供及服务消费工程中添加依赖，此依赖的作用是服务发现

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

1.3.2 服务注册

在服务提供工程中配置nacos服务发现相关的配置：

服务提供：

server:
  port: 56010
spring:
  application:
    name: nacos-restful-provider
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848

查看是否注册成功

启动nacos

启动服务提供

观察nacos服务列表，nacos-restful-provider注册成功

小结：

服务名称：每个服务在服务注册中心的标识，相当于Java中的类名。

服务实例：网络中提供服务的实例，具有IP和端口，相当于Java中的对象，一个实例即为运行在服务器上的一个进 程。

1.3.3 服务发现

在服务消费工程中配置nacos服务发现相关的配置： 服务消费：

nacos:  #自定义配置，下面可以直接调用
  server:
    addr: 127.0.0.1:8848
spring:   # 服务名称，在服务注册中心显示的服务名称
  application:
    name: nacos_consumer
  cloud:
    nacos:
      discovery:
        server-addr: ${nacos.server.addr} # 配置中心地址

修改Controller中远程调用的代码：

@Autowired
LoadBalancerClient loadBalancerClient;
// 服务生产者在服务注册中心的服务名，消费者可以根据生产者的服务名作为uri进行访问
private String serviceId = "nacos-restful-provider";

@GetMapping("service")
public String service() {
        RestTemplate restTemplate = new RestTemplate();
//调用服务
//  String providerResult = restTemplate.getForObject("http://" + providerAddress + "/service", 				String.class);
        ServiceInstance choose = loadBalancerClient.choose(serviceId);
        URI uri = choose.getUri();
        String providerResult = restTemplate.getForObject(uri + "/service", String.class);
        return "consumer invoke | " + providerResult;
    }

执行流程：

1、服务提供方将自己注册到服务注册中心

2、服务消费方从注册中心获取服务地址

3、进行远程调用

1.3.4 负载均衡

概念：

负载均衡就是将用户请求（流量）通过一定的策略，分摊在多个服务实例上执行，它是系统处理高并发、缓解网络 压力和进行服务端扩容的重要手段之一。它分为服务端负载均衡和客户端负载均衡。

服务端负载均衡

在负载均衡器中维护一个可用的服务实例清单，当客户端请求来临时，负载均衡服务器按照某种配置好的规则(负载均衡算法)从可用服务实例清单中选取其一去处理客户端的请求。这就是服务端负载均衡。

例如Nginx，通过Nginx进行负载均衡，客户端发送请求至Nginx，Nginx通过负载均衡算法，在多个服务器之间选择一个进行访问。即在服务器端再进行负载均衡算法分配。

客户端负载均衡

上边使用的LoadBalancerClient就是一个客户端负载均衡器，具体使用的是Ribbon客户端负载均衡器。

Ribbon在发送请求前通过负载均衡算法选择一个服务实例，然后进行访问，这是客户端负载均衡。即在客户 端就进行负载均衡的分配。

Ribbon是一个客户端负载均衡器，它的责任是从一组实例列表中挑选合适的实例，如何挑选？取决于负载均衡策略 。

Ribbon核心组件IRule是负载均衡策略接口，它有如下实现，大家仅做了解：

RoundRobinRule(默认):轮询，即按一定的顺序轮换获取实例的地址。

RandomRule:随机，即以随机的方式获取实例的地址。

AvailabilityFilteringRule: 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,以及并发的连接数量超 过 阈 值 的 服 务 , 然 后 对 剩 余 的 服 务 列 表 按 照 轮 询 策 略 进 行 访 问 ; WeightedResponseTimeRule: 根据平均响应时间计算所有服务的权重,响应时间越快,服务权重越大,被选中的机率越高;

刚启动时,如果统计信息不足,则使用RoundRobinRule策略,等统计信息足够时,会切换到

WeightedResponseTimeRule

RetryRule: 先按照RoundRobinRule的策略获取服务,如果获取服务失败,则在指定时间内会进行重试,获取可用的服务;

BestAvailableRule: 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,然后选择一个并发量最小的服务;

ZoneAvoidanceRule: 默认规则,复合判断server所在区域的性能和server的可用性选择服务器;

可通过下面方式在服务消费方的 配置文件中修改默认的负载均衡策略：

nacos-restful-provider: 
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

Nacos配置管理

2.1 理解配置中心

 2.1.1 什么是配置

        应用程序在启动和运行的时候往往需要读取一些配置信息，配置基本上伴随着应用程序的整个生命周期，比如：数据库连接参数、启动参数等。         

配置主要有以下几个特点：

• 配置是独立于程序的只读变量

        配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置 配置伴随应用的整个生命周期

        配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。 比如：启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。配置可以有多种加载方式

• 配置可以有多种加载方式

        常见的有程序内部hard code，配置文件，环境变量，启动参数，基于数据库等配置

        同一份程序在不同的环境（开发，测试，生产）、不同的集群（如不同的数据中心）经常需要有不同的配置，所以需要有完善的环境、集群配置管理。

2.1.2 什么是配置中心

        在微服务架构中，当系统从一个单体应用，被拆分成分布式系统上一个个服务节点后，配置文件也必须跟着迁移（分割），这样配置就分散了，不仅如此，分散中还包含着冗余。

配置中心的服务流程如下：

1、用户在配置中心更新配置信息。

2、服务A和服务B及时得到配置更新通知，从配置中心获取配置。

2.1.3 主流配置中心对比

        目前市面上用的比较多的配置中心有：Spring Cloud Config、Apollo、Nacos和Disconf等。由于Disconf不再维护，下面主要对比一下Spring Cloud Config、Apollo和Nacos。

        从配置中心角度来看，性能方面Nacos的读写性能最高，Apollo次之，Spring Cloud Config依赖Git场景不适合开放的大规模自动化运维API。

        功能方面Apollo最为完善，nacos具有Apollo大部分配置管理功能，而Spring Cloud Config不带运维管理界面，需要自行开发。Nacos的一大优势是整合了注册中心、配置中心功能，部署和操作相比Apollo都要直观简单，因此它简化了架构复杂度，并减轻运维及部署工作。

        综合来看，Nacos的特点和优势还是比较明显的，下面我们一起进入Nacos的世界。

2.2 Nacos配置管理

2.2.1 发布配置

首先在nacos发布配置，nacos_consumer服务从nacos读取配置。

浏览器访问 http://127.0.0.1:8848/nacos ，打开nacos控制台，并点击菜单配置管理->配置列表： 在Nacos添加如下的配置：

nacos-restful-consumer:

Namespace: public
DataID:  nacos_consumer.yaml
Group:  DEFAULT_GROUP
配置格式:      YAML
配置内容：    
common:
	name: application1 config

2.2.2 获取配置

要想从配置中心获取配置添加nacos-config的依赖：

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

在bootstrap.yml添加配置：

spring:
  cloud:
    nacos:
      config:
        server-addr: 127.0.0.1:8848 # 配置中心地址
        file-extension: yaml
        group: DEFAULT_GROUP

注意：要使用配置中心就要在bootstrap.yml中来配置，bootstrap.yml配置文件的加载顺序要比application.yml要优先。

在nacos-restful-consumer工程的controller中增加获取配置的web访问端点/configs，通过标准的spring注解@Value方式。

@Value("${common.name}") 
private String common_name;

@GetMapping(value = "/configs")
public String getvalue(){
	return common_name;
}

注意：单独加上读取配置中心代码时，会出现dubbo注册失败的问题，所以要保持之前的代码正常打开使用，可以在原application.yml中加上不检测依赖配置

dubbo:
  consumer:
    check: false

基于上面的例子，若要实现配置的动态更新，只需要进行如下改造：

// 注入配置文件上下文
@Autowired
private ConfigurableApplicationContext applicationContext;

@GetMapping(value = "/configs")
public String getConfigs(){
	return   applicationContext.getEnvironment().getProperty("common.name");
}

我们通过nacos控制台更新common.name的配置值，再次访问web端点/configs，发现应用程序能够获取到最新的配置值，说明spring-cloud-starter-alibaba-nacos-config 支持配置的动态更新。

Note 可以通过配置spring.cloud.nacos.config.refresh.enabled=false来关闭动态刷新。

2.2.3 配置管理模型

• 配置集(Data ID)

        在系统中，一个配置文件通常就是一个配置集，一个配置集可以包含了系统的各种配置信息，例如，一个配置集可 能包含了数据源、线程池、日志级别等配置项。每个配置集都可以定义一个有意义的名称，就是配置集的ID即Data ID。

• 配置项

        配置集中包含的一个个配置内容就是配置项。它代表一个具体的可配置的参数与其值域，通常以 key=value 的形式存在。例如我们常配置系统的日志输出级别（logLevel=INFO|WARN|ERROR） 就是一个配置项。

• 配置分组(Group)

         配置分组是对配置集进行分组，通过一个有意义的字符串（如 Buy 或 Trade ）来表示，不同的配置分组下可以有相同的配置集（Data ID）。当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景：可用于区分不同的项目或应用，例如：学生管理系统的配置集可以定义一个group为：STUDENT_GROUP。

• 命名空间(Namespace)

        命名空间（namespace）可用于进行不同环境的配置隔离。例如可以隔离开发环境、测试环境和生产环境，因为它们的配置可能各不相同，或者是隔离不同的用户，不同的开发人员使用同一个nacos管理各自的配置，可通过namespace隔离。不同的命名空间下，可以存在相同名称的配置分组(Group) 或 配置集。

2.2.4 获取某配置集的代码：

获取配置集需要指定：

1、nacos服务地址，必须指定

2、namespace，如不指定默认public。在config中指定namespace，例子如下：

config:
  server-addr: 127.0.0.1:8848 # 配置中心地址
  file-extension: yaml
  namespace: a1f8e863-3117-48c4-9dd3-e9ddc2af90a8 # 开发环境
  group: DEFAULT_GROUP # xx业务组

3、group，如不指定默认 DEFAULT_GROUP

4、dataId，必须指定，名称为应用名称+配置文件扩展名

2.3 自定义配置

2.3.1 ext-config扩展配置

Spring Cloud Alibaba Nacos Config可支持自定义 Data Id 的配置。 一个完整的配置案例如下所示：

server:
  port: 56020
nacos:
  server:
    addr: 127.0.0.1:8848
provider:
  address: 127.0.0.1:56010
spring:
  application:
    name: nacos_consumer
  cloud:
    nacos:
      discovery:
        server-addr: ${nacos.server.addr}
      config:
        server-addr: ${nacos.server.addr} # 配置中心地址
        file-extension: yaml
        ext-config[0]:
          data-id: ext-common.yaml
          group: COMMON_GROUP
          refresh: true

可以看到:

通过 spring.cloud.nacos.config.ext-config[n].data-id 的配置方式来支持多个 Data Id 的配置。

通过 spring.cloud.nacos.config.ext-config[n].group 的配置方式自定义 Data Id 所在的组，不明确配置的话，默认是 DEFAULT_GROUP。

通过spring.cloud.nacos.config.ext-config[n].refresh 的配置方式来控制该 Data Id 在配置变更时，是否支持应用中可动态刷新， 感知到最新的配置值。默认是不支持的。

spring.cloud.nacos.config.ext -config[n].data-id 的值必须带文件扩展名，文件扩展名既可支持 properties，又可以支持 yaml/yml。 此时 spring.cloud.nacos.config.file -extension 的配置对自定义扩 展配置的 Data Id 文件扩展名没有影响。

配置ext-config-common01.yaml：

配置ext-config-common02.yaml：

使用：

 @GetMapping(value = "/configs") 
    public String getvalue(){
        String name = applicationContext.getEnvironment().getProperty("common.name");
        String address =  applicationContext.getEnvironment().getProperty("common.addr");
        return  name+address;
    }

重启nacos-restful-consumer工程

访 问 ：http://127.0.0.1:56020/configs 通过测试发现：

扩展配置优先级是 spring.cloud.nacos.config.ext -config[n].data-id 其中 n 的值越大，优先级越高。 通过内部相关规则(应用名、扩展名 )自动生成相关的 Data Id 配置的优先级最大。