nacos功能特性,使用nacos的好处

nacos微服务（一）

Nacos 提供了一组简单易用的特性集，帮助您快速实现 动态服务发现、服务配置、服务元数据 及 流量管理。

Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

【Nacos专题】Nacos Config

【专题回顾】

【Nacos专题】Nacos 快速入门

【Nacos专题】Nacos 集群搭建

Nacos 既可以作为注册中线，提供服务注册与发现；又是配置中心，提供配置的动态管理。Nacos 既能支持 properties 类型的配置，也能支持 ymal 类型的配置。

为了满足 多租户、多环境、多服务 配置隔离的需求，Nacos 提供了 Data Id 、 Group 以及 Namespace 不同管理级别的概念，利用 Nacos 定义的层级关系，用户可以非常方便的管理多环境的配置。

Data Id 的完成格式如下：

完整的 Data Id 由 3 部分构成，具体格式说明如下：

示例：

如果 Data Id 的值为 nacos-config-dev.properties ，则在 bootstrap.properties 配置如下：

如下图所示，用 Data Id 来区分开发、测试、生产环境配置：

在分布式系统中，我们经常会根据业务来对系统进行水平拆分，业务独立的模块单独构成一个系统，从而实现业务解耦。Nacos 的 Group 能够很好的应对分布式系统的配置管理。 Group 是 Data Id 的集合，按照业务系统来定义 Group ，然后再在每个 Group 下按照 dev 、 test 、 prod 来区分环境，这样整个系统配置就非常的清晰明了。

在 Nacos 服务端定义完分组后，还需要在项目中通过 spring.cloud.nacos.config.group 配置来指定分组， 这样在项目启动的时候，就能拉取指定分组下的配置。

如下图所示，为订单系统创建分组：

Namespace 是用于在多租户之间进行配置隔离，不同的 命名空间 下，可以存在相同的 Group 和 Data Id ，再配合 Nacos 的权限管理功能，针对用户角色(多组合)，进行 Namespace 级别的读写权限控制。

Nacos 默认命名空间为 public ，当在新建一个 Namespace 时，Nacos会生成一个唯一标识UUID，在项目中通过 spring.cloud.nacos.config.namespace 来指定命名空间。

Dubbo与Nacos的区别两者是不是有重叠？

没有重叠，只是两者侧重点不一样。Nacos主要功能集中在动态服务发现、服务配置、服务元数据及流量管理。你可以把他简单的理解为是一个注册中心和配置中心，而Dubbo是一款高性能、轻量级的开源Java服务框架，主要功能点在于RPC框架。

Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力，面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。

监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。

【Nacos专题】Nacos 快速入门

Nacos 英文全称 Dynamic Naming and Configuration Service，它是 Spring Cloud Alibaba 的核心组件之一，致力于微服务架构中的服务注册与发现、配置管理。

Nacos 将注册中心和配置中心整合在一起，提供了两个核心功能，即服务注册与发现和动态配置服务。

Nacos 支持基于 DNS 和 基于 RPC 的服务发现，服务提供者向 Nacos 服务端注册服务后，服务消费者可以从 Nacos 服务端获取注册列表。

提供了一个简洁易用的 UI，方便用户管理所有环境的应用配置和服务配置，消除了配置变更时服务需重新部署的过程。还提供了包括 配置版本跟踪 、 金丝雀发布 、 一键回滚配置 以及 客户端配置更新状态跟踪 在内的一系列开箱即用的配置管理特性，大大降低配置变更带来的风险。

Nacos 分为服务端和客户端，服务端用来提供服务发现与注册等功能，客户端就是不同的应用和服务。

在 Nacos 的 Release Notes 可以看到每个版本的相关介绍。当前最新的稳定版本是 1.4.0。

Nacos 服务需要 Java 运行环境，因此，在启动服务之前需要确保你的服务器已经有了 Java 运行环境，并且配置好了 JAVA_HOME 。

参数说明：

-m：指定运行模式，standalone 表示单机模式

在 Nacos 配置文件中配置服务器ip，默认的端口号为8848，默认的用户名和密码均为nacos，访问 便能够成功登Nacos管理后台。

(1) 引入依赖

在 SpringBoot 项目中引入 Nacos 客户端依赖，pom.xml 添加如下内容：

(2) 修改配置

在 application.properties 配置文件中添加 Nacos 的基本配置 (也可以是 application.yml )

1）application.properties

2）application.yml

(3) @EnableDiscoveryClient 注解

在 SpringBoot 的启动类上添加 @EnableDiscoveryClient 注解来开启服务注册。

Nacos Discovery 默认集成了 Netflix Ribbon，服务消费者可以使用 RestTemplate 或 OpenFeign 进行服务的调用。

(1) Nacos 启动时报如下错误

问题原因：通过yum命令安装的普通的openJDK没有javac等工具，而且安装完以后连环境变量都不需要配置，就能使用 java -version 验证。

解决方案：重新安装devel开发版openJDK，开发版的openJDK有javac工具，然后配置java环境变量即可。

(2) Nacos Provider 启动报错

问题原因：没有配置 Nacos 服务端的地址，因此，当 Nacos Provider 启动的时候，无法与注册中心通信

解决方案：在配置文件中配置 Nacos 服务端地址，如下所示：

Nacos服务发现

Nacos 另一个非常重要的特性就是服务注册与发现，说到服务的注册与发现相信大家应该都不陌生，它们是服务治理的最基础功能。

Nacos 支持几乎所有主流类型的 “服务” 的发现、配置和管理。

了解过 Dubbo 的同学，应该对 Dubbo 的架构非常熟悉，最经典的一张架构图如下所示：

图中的6个步骤的含义解释如下：

0、服务容器负责启动，加载，运行服务提供者。

1、服务提供者在启动时，向注册中心注册自己提供的服务。

2、服务消费者在启动时，向注册中心订阅自己所需的服务。

3、注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4、服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5、服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

其中图中最上方的 Registry 就是注册中心，负责服务的注册与发现。Dubbo 有自己的 Registry 实现，而 Nacos 则是另一种 Registry 实现。

相对服务注册而言服务发现就简单很多了。就是Nacos客户端调用Open API或者SDK查询服务列表，服务端接受到请求后根据将查询到服务包装成json格式返回。

既然如此，客户端是啥时候发起服务列表查询？

如果客户端查的时差内，刚好有服务实例有down掉，那客户端的请求岂不是有请求到刚好down的服务实例？下面进行解答。

客户端有一个HostReactor类，在com.alibaba.nacos.client.naming.core包下。

HostReactor它里面有一个UpdateTask线程，每 1s 发送一次pull拉取请求，获取服务最新的地址列表。

更新服务的核心逻辑在updateService方法中：

再看看processServiceJson方法， 本地维护一个MapString,ServiceInfo serviceInfoMap 存储服务信息，同时调用 DiskCache.write(serviceInfo, this.cacheDir) 方法把服务信息写入本地缓存文件中;

服务端采取的是基于push的方式向客户端通知，由于服务端和服务提供者（各个微服务provider）建立了心跳机制，一旦某个服务出现故障，服务端察觉出后，会发送一个push消息给Nacos客户端，也就是我们的消费者。这个push消息是使用DatagramSocket来实现的。

服务消费者收到服务端发来的push消息之后，使用HostReactor中提供的ServiceInfo processServiceJson(String json)方法解析消息，并更新本地服务地址列表。

可以参照下面的图更容易理解服务动态感知原理，包括：客户端主动轮训查询服务列表及服务端Push变故后的服务列表。

一、Nacos介绍

6月份阿里开源的Nacos发布了1.0.1版本，从去年7月份第一个release版本到现在一直在默默关注

官方的版本规划为：Nacos从0.8.0开始支持生产可用，1.0版本可大规模生产可用，2.0版本接入k8s、SpringCloud、ServiceMesh、ServerLess

公司目前的项目都是Springcloud，由于eureka2.X的断更、以及Nacos面世，所以自然而然最近就进行了一次试水爬坑，虽然过程艰苦，但是最终效果似乎还不错。

本文主要从以下几点来带大家熟悉下Nacos

Nacos是什么？好像没听过，不要紧。那Eureka听说过吧，在SpringCloud中做服务注册中心组件，类似的还有Zookeeper、Consul。

所以Nacos也是一个注册中心组件咯，当然是，不过 它不仅仅是注册中心 。

Nacos也是一个配置中心 ，比如SpringCloud中的Config，将配置文件版本化管理。

那么Nacos到底是什么呢, 总结为官网一句话就是:

首先要说Nacos的发展历程就要从阿里巴巴的内部产品ConfigServer说起了，因为 Nacos是ConfigServer 的开源实现

早在2008年阿里就开始服务化的进程(那个时候我好像还在上初中啊)，在那个时候阿里内部自研的服务发现解决方案就叫做ConfigServer

ConfigServer经历了十年的发展从V1.0的单机版演变为目前对外公布的V4.0集群版。

2018年7月阿里巴巴高级技术专家许真恩（慕义）发布了Nacos首个开源版本V0.1.0，Nacos作为ConfigServer的开源实现截止目前已经更新到了V1.0.1的大版本，并且支持大规模生产版本。

虽然 官方文档 也有介绍，但是语言比较官方，我就用大白话谈一点自己的使用感受。

首先先上一张官方的生态图

除了对于阿里开源生态体系如 Dubbo 等自身的支持，也非常强调融入其它的开源生态，这里就包括 Java 的微服务生态体系 Spring Cloud，Kubernetes/CNCF 云原生生态体系。

Nacos 无缝支持 Spring Cloud，为 Spring Cloud 用户其提供更简便的配置中心和注册中心的解决方案。

Nacos支持目前几乎所有主流的微服务生态体系。

Nacos从官方的介绍上看，就像是SpringCloud中Eureka+Config+Bus+Git+MQ的一个结合体，当然也不能完全这么理解。Nacos是脱胎于阿里内部的ConfigServer，而ConfigServer早在3.0版本就解决了Eureka在1.0版本留下的隐患，所以从技术的更新和迭代角度来看，稳定版本的Nacos将更适合做为微服务体系中的服务注册发现组件，当然了他也不单单只是注册和发现。更多的特性和功能，不如一起搭建试试吧。

Nacos官方手册