本文来说下Nacos是什么
概述
Nacos 的官网地址为：
https://nacos.io
上图为首页截图，已经明确的说明了 Nacos的2个核心作用：
- 服务发现
- 配置管理
所以 Nacos 可以作为服务注册中心、配置中心。
Nacos 这个名字怎么读呢？它的音标为 /nɑ:kəʊs/。这个名字不是一个标准的单词，而是以下单词的首字母缩写
Name and Config Service
从命名中也可以看出 Nacos 的功能了。
从上图中可以看到，Nacos 的网站是中文的，
这是因为 Nacos 是国产的，是阿里开源的
。
阿里为 SpringCloud 贡献了一个子项目，叫做 SpringCloud Alibaba，其中包括了微服务开发中的几个基础组件，Nacos 就是此项目中的一项技术。
SpringCloud Alibaba 可以对标 SpringCloud 中老牌的主流项目 SpringCloud Netflix（包括 Eureka、Hystrix、Zuul 等等），也是一个技术集，包括：
可以看到，主要技术有：
- Sentinel – 提供流控、服务降级、熔断能力，为系统提供防护。
- Nacos – 负责服务注册与发现，还有分布式配置。
- RocketMQ – 用于实现事件驱动模式、消息总线，已经整合了 SpringCloud Stream。
- Seata – 用于实现分布式事务。
- Dubbo RPC – 使用 RPC 进行服务调用。
现在已经清楚 Nacos 是什么了，它是阿里开源的 SpringCloud Alibaba 项目下的一项技术，可以实现服务注册中心、分布式配置中心。
下面大概浏览一下 Nacos 的控制台界面，看看主要的功能。
服务管理
配置管理
服务发现概念简介
分布式系统中，包含多个独立的服务，
服务之间存在需要调用的需求，应该如何调用
？
服务调用时必须知道目标服务实例的 IP、端口、API 接口。
其中 API 信息可以通过服务接口文档中获知，但 IP、端口 都是动态的，每次部署服务实例的时候可能都会变。
知道了目标服务实例的地址，就相当于发现了对方。具体怎么发现目标服务？这就是
服务发现机制
。
如上图，在服务实例数量少的时候，每个服务实例可以自己维护相关服务实例的地址信息，也就是自己维护一个通讯录。
例如通过配置文件来记录，相关服务实例地址发生变更的时候就修改一下，有点麻烦，但还可以忍受。
但是，当服务实例数量变大之后，就无法自己维护了，相关服务数量多、地址变化频繁。
此时必须有一种更优的发现机制，就出现了
服务注册中心
。
如上图，每个服务实例启动之后，都主动向注册中心登记自己的地址信息，这样注册中心便拥有了所有服务实例的记录，类似于
查号台
。
当某个服务实例停止运行的时候，主动让注册中心销毁自己的信息。
如果服务实例不是主动停止，而是因为故障等原因死掉的，如何处理？需要注册中心能够主动清理。
注册中心要能够实时知道各个服务实例的状态，通过
心跳机制
来实现，实例定时向注册中心发送请求，表明自己还活着，如果心跳没了，注册中心就可以对其清理。
一个服务实例在调用另一个服务时，可以根据服务名称从注册中心获取此服务的实例信息列表，从中选取一个实例进行调用。
以上就是注册中心这种服务发现机制的工作方式。
分布式配置概念简介
每个服务都会有自己的配置信息，例如 SpringBoot 项目中的配置文件，服务运行时会读取配置文件中的配置项。
一个服务通常会启动多个实例，来提供其可靠性，那么每个实例中就都会包含这个配置文件，一个服务的各个实例中配置都是相同的。
如果要改某个配置项的值，怎么办？
修改配置文件，然后重新部署此服务的所有实例。麻烦低效。
如果把服务的配置信息提出来，不放在自己的配置文件中，而是放到一个第三方的配置中心，服务实例从配置中心读取属于自己的配置，而且，在配置中心里面修改配置项之后，所有相关实例都可以立即拿到最新值，不用重新部署了，这样就方便很多。
所以分布式配置有2大好处：
- 方便维护，集中维护优于分散式维护每个服务的配置文件。
- 动态更新，配置修改后直接生效，不用重新部署。
此外，Nacos 还可以做配置的版本管理，轻松实现历史版本的回滚。
本文小结
本文大概介绍了什么是Nacos以及基本原因，在服务的注册与发现上，与Eureka和zk的使用差不多。