本文由读者 muggle 投稿，muggle 是一位具备极客精神的 90 后单身老实猿，对技术有着狂热追求
nacos 简介
在 nacos-0.3 的时候我就开始关注，期间还写过一篇作为 Spring Cloud 配置中心的使用记录的博客。在前不久，nacos 终于出了正式版，赶个时髦出篇博客吹一波。
nacos 特性
服务发现和服务健康监测
支持基于 DNS 和基于 RPC 的服务发现（可替代 eureka ）。Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 ( PING 或 TCP )和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。 对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助开发者根据健康状态管理服务的可用性及流量。
动态配置服务
动态配置服务可以让开发者以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置（可以作为配置中心）。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。Nacos 提供了一个简洁易用的 UI 帮助开发者管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助开发者更安全地在生产环境中管理配置变更和降低配置变更带来的风险。
动态 DNS 服务
动态 DNS 服务支持权重路由，让开发者更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务（可做负载均衡）。动态DNS服务还能让开发者更容易地实现以 DNS 协议为基础的服务发现，以帮助开发者消除耦合到厂商私有服务发现 API 上的风险。
服务及其元数据管理
Nacos 能让开发者从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。
nacos的相关概念
•地域 （Region）：物理的数据中心，资源创建成功后不能更换。•可用区（Available Zone）：同一地域内，电力和网络互相独立的物理区域。同一可用区内，实例的网络延迟较低。•接入点（Endpoint）：地域的某个服务的入口域名。•命名空间（Namespace）：用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。•元信息(Metadata)：Nacos 数据（如配置和服务）描述信息，如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签 (label)，从作用范围来看，分为服务级别的元信息、集群的元信息及实例的元信息。•实例（Instance）：提供一个或多个服务的具有可访问网络地址（IP:Port）的进程。•权重（Weight）：实例级别的配置。权重为浮点数。权重越大，分配给该实例的流量越大。•健康检测（Health Check）：以指定方式检查服务下挂载的实例 (Instance) 的健康度，从而确认该实例 (Instance) 是否能提供服务。根据检查结果，实例 (Instance) 会被判断为健康或不健康。对服务发起解析请求时，不健康的实例 (Instance) 不会返回给客户端。•健康保护阈值（Protect Threshold）：为了防止因过多实例 (Instance) 不健康导致流量全部流向健康实例 (Instance) ，继而造成流量压力把健康 健康实例 (Instance) 压垮并形成雪崩效应，应将健康保护阈值定义为一个 0 到 1 之间的浮点数。当域名健康实例 (Instance) 占总服务实例 (Instance) 的比例小于该值时，无论实例 (Instance) 是否健康，都会将这个实例 (Instance) 返回给客户端。这样做虽然损失了一部分流量，但是保证了集群的剩余健康实例 (Instance) 能正常工作。•服务分组（Service Group）：不同的服务可以归类到同一分组。•虚拟集群（Virtual Cluster）：同一个服务下的所有服务实例组成一个默认集群, 集群可以被进一步按需求划分，划分的单位可以是虚拟集群。
nacos 使用
安装
可在 GitHub 上下载安装包安装，或者采用 docker 安装。
Windows 上运行：
在 GitHub 查看该项目的 releases 并下载最新版，解压后进入 bin 目录 运行 startup.cmd 。
docker 上运行：
docker run --name nacos-standalone -e MODE=standalone -p 8848:8848 nacos/nacos-server:latest
可运行一个单机版nacos
浏览器上访问 ip:8848/nacos 进入登陆界面，用户名和密码都是 nacos；登陆成功就能看到控制台 UI 界面了。在安装包的 ./conf 目录下有一个 application.properties 文件，这是 nacos 的配置文件。
作为配置中心
示例
这里为方便讲解，我们现在 Windows 环境下运行一个单机版 nacos ，启动后登陆，创建一个 SpringBoot 应用，导入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-alibaba-nacos-config</artifactId>
<version>0.9.0.RELEASE</version>
</dependency>
然后删除 application.properties 新建一个 bootstrap.properties 。这里可能还有同学不知道 application 和 bootstrap 的区别，在这里科普一下：在 Spring Boot 中有两种上下文，一种是 bootstrap , 另外一种是 application , bootstrap 是应用程序的父上下文，也就是说 bootstrap 加载优先于 application 。bootstrap 主要用于从额外的资源来加载配置信息，还可以在本地外部配置文件中解密属性。这两个上下文共用一个环境，它是任何 Spring 应用程序的外部属性的来源。bootstrap 里面的属性会优先加载，它们默认也不能被本地相同配置覆盖。bootstrap 比 application 要先加载，bootstrap 只在 cloud 项目中使用。
添加配置：
#服务名
spring.application.name=nacos-config-example
# 配置中心url
spring.cloud.nacos.config.server-addr=127.0.0.1:8848
# 配置中心的配置语法
spring.cloud.nacos.config.file-extension=properties
现在在 nacos 配置中心新建配置：
dataId:nacos-config-example.properties
启动项目，发现项目端口号是8082，我们的配置成功了。
说明
注意 图中几个选项 TEXT\JSON\ XML \YAML\ HTML\Propertiest 这些并不是指定 nacos 以何种语法去解析配置文件，仅仅是提供语法提示，代码高亮辅助样式；第一次使用的人很容易被误导。我们要指定配置文件语法要在bootstrap做如下配置：
spring.cloud.nacos.config.file-extension=properties
spring.cloud.nacos.config.file-extension=yaml
配置中心配置依靠dataId将配置信息和客户端绑定，我们来看看dataId组成规则：
${prefix}-${spring.profile.active}.${file-extension}•
prefix 默认为 spring.application.name 的值，也可以通过配置项 spring.cloud.nacos.config.prefix 来配置。
•
spring.profile.active 即为当前环境对应的 profile ， 注意：当 spring.profile.active 为空时，对应的连接符 - 也将不存在，dataId 的拼接格式变成 ${prefix}.${file-extension}
•
file-exetension 为配置内容的数据格式，可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。目前只支持 properties 和 yaml 类型。
也就是说我们这个配置中心的 dataId 和我们平时用 Spring Boot 命名配置文件只有一个 prefix 的区别
现在我们来修改一下配置文件，bootstrap 加一项：
spring.cloud.nacos.config.prefix=config-test
spring.profiles.active=dev
配置中心弄两个配置方便比较，一个 dataId 是 config-test-dev.properties ，一个 dataId 是 config-test-prod.properties 配置端口号分别为 8081 和 8082 测试。启动项目后发现项目端口号为 8081，然后修改配置重启：
spring.profiles.active=prod
此时端口变成了 8082。用法和 Spring Boot 的配置文件区别不大。
命名空间和分组
命名空间和分组相当于一个配置文件的"年级和班次"，在同一个 group 下，配置文件名不能重复，所以当需要创建文件名称相同的两个配置文件时，将两个配置文件创建在不同的 group 下即可。而 namespace 范围比 group 大，目的是一样的。
定义命名空间方式如图
在bootstrap中对应配置
spring.cloud.nacos.config.namespace=命名空间ID
分组则在配置中心新建配置的时候可指定，在bootstrap中对应配置
spring.cloud.nacos.config.group=group
配置自动更新
通过 Spring Cloud 原生注解 @RefreshScope 实现配置自动更新，示例：
@Service
@RefreshScope
public class ConfigController {
@Value("${config.test}")
private String test;
public void testStr(){
System.out.print(test)
}
}
当你在配置中心更新 config.test 的 客户端的 test 的值也会刷新，并且你还能在客户端看到值变更的相关日志。
小结
别的不说，这比 Spring Cloud Config 好用太多了有木有! 和 apollo 比起来配置太容易了有木有!这么好用的东西，出正式版了，等坑都排完了妥妥的神器有木有!我选 nacos ，你呢？
作为注册中心
刚才是作为配置中心，接下来再来看看 nacos 作注册中心。
介绍
服务治理是微服务架构中最为核心和基础的模块。它主要用来实现各个微服务实例的自动化注册与发现。随着服务的越来越多，越来越杂，服务之间的调用会越来越复杂，越来越难以管理。而当某个服务发生了变化，或者由于压力性能问题，多部署了几台服务，怎么让服务的消费者知晓变化，就显得很重要了。不然就会存在调用的服务其实已经下线了，但调用者不知道等异常情况。这个时候有个服务组件去统一治理就相当重要了。注册中心便是做这个事情的，我们的服务上下线和发现服务都要依赖于注册中心。
nacos 注册中心有哪些特性呢？首先 nacos 从 cap 的角度来说，它能针对不同模式采用 cp 还是 ap 原则。然后它对服务发现的支持种类也有很多，比如：gRpc、Dubbo RpcService、Spring Cloud RESTful Service 。并且 nacos 本身提供了很直观的注册中心管理界面。方便我们查看管理服务，其 api 也很丰富，我们完全可以在做二次开发去写一个我们自己满意的管理页面。Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。
示例
新建一个 Spring Boot 项目，添加如下依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
<version>0.9.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter</artifactId>
<version>2.1.1.RELEASE</version>
</dependency>
在启动类上加上 @EnableDiscoveryClient 注解
@SpringBootApplication
@EnableDiscoveryClient
public class MytestApplication {
public static void main(String[] args) {
SpringApplication.run(MytestApplication.class, args);
}
}
application添加配置:
server.port=8081
spring.application.name=service-mytest
spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
启动服务后，我们能看到nacos管理页面注册上了一个服务。点击查看详情：
列表上有一列是临时实例，临时实例通常使用 AP 一致性，因此如果发生网络分区，注册临时实例仍然有效。持久化实例使用 CP 一致性，这保证了数据的一致性。而持久化配置则是配置集群和数据库，本文不做介绍。后期搭建集群的时候我们在做测试。权重则是指调用服务时路由到该实例的优先系数，数字越大优先级越高，为0则不会使用该实例。
总结
我们能用 nacos 作为配置中心或者注册中心，其本身提供管理界面也很方便。nacos 的使用企业也很多，下面放出一张 github 上 nacos 的使用企业截图：
官方文档还有提到 nacos 支持动态 DNS，也就是说支持 DNS 的负载均衡，但本人没找到很好的资料，后续再做研究。关于 nacos 集群和持久化配置搭建后续更新，感谢阅读。
关注牧码小子，后台回复 Java ，领取松哥为你精心准备的Java干货！
