Nacos入门指南01 - Nacos是什么？

你好，欢迎阅读，本文是系列文章中的第1篇。

Part1 - Nacos 是什么？

Part2 - Nacos 环境搭建

Part3 - Nacos 服务发现实践

Part4 - Nacos 分布式配置实践

本文的目标是理解 Nacos 的概念作用，并理解服务发现与分布式配置的概念。

1. 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 的控制台界面，看看主要的功能。

• 服务管理

• 配置管理

2. 服务发现概念简介

分布式系统中，包含多个独立的服务，服务之间存在需要调用的需求，应该如何调用？

服务调用时必须知道目标服务实例的 IP、端口、API 接口。

其中 API 信息可以通过服务接口文档中获知，但 IP、端口 都是动态的，每次部署服务实例的时候可能都会变。

知道了目标服务实例的地址，就相当于发现了对方。具体怎么发现目标服务？这就是服务发现机制。

如上图，在服务实例数量少的时候，每个服务实例可以自己维护相关服务实例的地址信息，也就是自己维护一个通讯录。

例如通过配置文件来记录，相关服务实例地址发生变更的时候就修改一下，有点麻烦，但还可以忍受。

但是，当服务实例数量变大之后，就无法自己维护了，相关服务数量多、地址变化频繁。

此时必须有一种更优的发现机制，就出现了服务注册中心。

如上图，每个服务实例启动之后，都主动向注册中心登记自己的地址信息，这样注册中心便拥有了所有服务实例的记录，类似于查号台。

当某个服务实例停止运行的时候，主动让注册中心销毁自己的信息。

如果服务实例不是主动停止，而是因为故障等原因死掉的，如何处理？需要注册中心能够主动清理。

注册中心要能够实时知道各个服务实例的状态，通过心跳机制来实现，实例定时向注册中心发送请求，表明自己还活着，如果心跳没了，注册中心就可以对其清理。

一个服务实例向调用另一个服务时，可以根据服务名称从注册中心获取此服务的实例信息列表，从中选取一个实例进行调用。

以上就是注册中心这种服务发现机制的工作方式。

3. 分布式配置概念简介

每个服务都会有自己的配置信息，例如 SpringBoot 项目中的配置文件，服务运行时会读取配置文件中的配置项。

一个服务通常会启动多个实例，来提供其可靠性，那么每个实例中就都会包含这个配置文件，一个服务的各个实例中配置都是相同的。

如果要改某个配置项的值，怎么办？

修改配置文件，然后重新部署此服务的所有实例。麻烦低效。

如果把服务的配置信息提出来，不放在自己的配置文件中，而是放到一个第三方的配置中心，服务实例从配置中心读取属于自己的配置，而且，在配置中心里面修改配置项之后，所有相关实例都可以立即拿到最新值，不用重新部署了，这样就方便很多。

所以分布式配置有2大好处：

• 方便维护，集中维护优于分散式维护每个服务的配置文件。
• 动态更新，配置修改后直接生效，不用重新部署。

此外，Nacos 还可以做配置的版本管理，轻松实现历史版本的回滚。