前言

说到微服务，注册中心是避不开的话题。在微服务中注册中心的主要功能就是提供服务发现、服务注册这两个功能。市面上的注册中心种类非常多，今天我就讲讲阿里的开源产品 Nacos。

快速构建

源码下载

地址

本地编译

参考官网的Download source code from Github 。

启动

参考官网Start Server 。本地启动的时候一定要加-m standalone

Naming+Config=Nacos

从Nacos官网上我们其实也了解到，Nacos分为两个部分。一个是命名服务，另一个是分布式配置，接下来会分开介绍

分布式系统中的命名服务

命名服务的定义看这里 。简单来说在分布式系统中的命名服务的作用主要是给系统中的每个RPC服务分配一个资源符号，命名服务通过这个资源符号能得到这个RPC服务的详细信息以及所有提供这些服务的机器信息。

为什么需要命名服务？

在进行服务调用时有两个信息至关重要，一是我要调用的最新的服务信息（RPC信息、地址信息）。如果不知道服务信息我们是无法调用的，而如果我们的服务信息不是最新的，那又会因为服务信息的不一致导致调用异常（试想下，如果你还在用旧的地址信息，而后端服务这个时候换了机器部署，那就会出现调用异常的情况。同理，后端服务信息发生变更，比如：方法签名发生变更。使用旧的信息仍然会出现调用失败的情况）。一是保证调到正常提供服务的机器上（可能有版本发布或是机器异常的情况，需要剔除掉这些信息）。正式基于这两点，我们需要一个服务能够管理服务的注册信息。

命名服务的主要功能点

信息推送

前面我们讲到了，必须让应用能时刻保持最新的服务信息，而实现这一功能的手段就是消息推送。消息推送的形式有很多种，比如：TCP全双工、UDP广播、回调，这些方式都可以实现。

心跳检测

当然，为了提升服务的可用性，异常服务的剔除也是必不可少的。而实现它的方式就是心跳检测，基于一个固定的时间去发送“ping命令”检查服务的情况。

Nacos中的命名服务

数据结构

上图是Dubbo启动后会注册两个服务，以及它的订阅者。可以看到Nacos的数据结构和Zookeeper的数据结构有很大的不一样。Nacos是基于Key-Value的结构，而Zookeeper是基于一种树形结构。

数据类型

和 Zookeeper 一样 Nacos 也分为两种节点，临时节点和永久节点，临时节点会和创建这个节点的应用建立心跳检测机制用于保证这个机器可达（服务健康检查也是基于这个机制）。而永久节点一经创建就不会被 Nacos 删除，除非你通过删除操作来删除。

分布式系统中的配置服务

配置服务也叫配置中心，用于管理整个系统的配置。提供简单的读写接口、实时更新到系统中各个机器上、自动载入到系统中。

为什么需要配置服务

在开发过程中我们会经常用到配置，比如：应用启动参数配置、业务参数配置等等。对于系统启动配置，我们希望有多个配置，能够针对不同的环境自动匹配（类似Spring的@Profile，可以让配置绑定特定环境）。针对应用业务配置，我们希望配置能被很好的管理，他的生命周期能和应用独立开（在以前配置都是散落在各个机器上，每个机器上都有一份，而且是散落在各个地方，我们没有一个很好的办法去同时修改这些配置文件）。当然，我们现在的业务系统很多业务逻辑，经常会遇到需要禁用某个功能或是有多个功能，这些功能的切换或者功能的禁用都需要基于配置，而传统的配置很难做到统一变更管理，统一的推送。

Nacos中的配置服务

Nacos 基于上面三点做了一个很好的实现，但是在使用时也需要注意配置并不支持高并发的变更（当然也没有高并发的实际场景，所有配置服务都要注意不能高并发更新）。

写在最后

本篇文章只从功能特点上来看 Nacos，主要为了引入分布式系统中的命名服务和配置服务这两个概念，后面会专门从源码实现层面讲。附录里面最后3个链接是 Nacos 和其他同类产品的对比，因为作者们的视角不同，因此需要大家看的时候舍弃部分重复的内容。

附录

Nacos Spring Boot 服务注册发现框架比较 服务注册与发现框架对比 微服务架构 - 服务发现、配置中心对比 - Nacos