Nacos 是什么
Nacos 在阿里巴巴起源于 2008 年五彩石项目，该项目完成了微服务拆分和业务中台建设，随着云计算和开源环境的兴起，2018 年,将 Nacos 开源，输出阿里十年关于服务发现和配管管理的沉淀，推动微服务行业发展，加速企业数字化转型。
Nacos 是集配置中心和服务注册与发现于一身的微服务基础设施。致力于解决微服务架构中的配置中心、服务注册与发现等问题，它提供了一套简单易用的特性集，帮助开发者快速实现动态服务发现、服务配置、服务元数据、流量管理及统一配置。
现在服务注册发现的技术已经非常成熟，配置中心和服务注册与发现的一站式解决方案貌似也成为了行业的主流，包括比较成熟的 etcd、consul 等也都是即可以当做配置心中使用，又可以当做服务注册与发现使用。
特性
易于使用
- 动态配置管理、服务注册与发现的一站式解决方案
- 20多种开箱即用的以服务为中心的架构特性
- 基本符合生产要求的轻量级易用控制台
更适应云架构
- 无缝支持Kubernetes和Spring Cloud
- 在主流公共云上更容易部署和运行（例如阿里云和AWS）
- 多租户和多环境支持
生产等级
- 脱胎于历经阿里巴巴10年生产验证的内部产品
- 支持具有数百万服务的大规模场景
- 具备企业级SLA的开源产品
丰富的应用场景
- 支持限流、大促销预案和异地多活
- 直接支持或稍作扩展即可支持大量有用的互联网应用场景
- 流量调度和服务治理
配置中心
Nacos 配置中心可以通过 client SDK 或 控制台来发布配置，将配置的信息交由 Nacos 来保存。可以为用户提供外部化配置文件、动态修改、即时生效。解决因配置变更要重启服务带来的风险与困扰。Nacos 的配置中心包含以下特性：
- 提供对配置信息的生命周期管理，增删改查。
- 支持多种格式的配置信息配置，例如：text、json、xml、yaml、html、properties。
- 支持配置版本管理，可以进行版本恢复。
- 支持配置灰度功能，可以针对指定 ip 进行灰度测试。
- 支持配置监听，变更实时推送。
服务注册与发现
Nacos 服务注册与发现基于内存进行服务实例信息及元数据的声明周期管理，服务在启动的时候将服务实例注册到 Nacos 中，并在关闭的时候注销服务实例。Nacos 的服务注册与发现包含一下特性：
- 支持对服务信息及元数据的生命周期管理，增删改查。
- 支持负载均衡策略。
- 支持对服务实例的健康状态检查、服务权重管理。
Nacos 架构
下面的架构图是 Nacos 2.x 的架构图，在 1.x 的基础上增加了 gRPC、Rsocket 实现了长链接和 RPC 调用和推送能力。解决 1.x 下的 http 短连接模型的性能问题。
接入层：Nacos 提供了 client SDK 和 OpenAPI 来提供和 Nacos 交互的能力。
协议层：目前支持 gRPC、Rsocket、HTTP、UDP 协议。
链接层：主要负责处理请求、流量控制、负载均衡等操作。
功能层：面有服务注册与发现、配置管理。这块就是的核心业务层。
数据一致性层：Nacos 提供了两种协议。分别是 AP 模式的 Distro 和 CP 模式的 Raft。
- Distro：非持久化服务的同步模式。
- Raft：持久化服务的同步模式、以及使用 Derby 作为配置的存储时同步配置操作。
持久化层：Nacos 使用 MySQL 、Derby 和 本地文件来做持久化。配置信息、用户信息、权限等存储在 MySQL 和 Derby 中。服务实例以及服务元数据等信息存储在内存和本地文件中。
Nacos 解决了什么问题
从分布式系统的角度来看，Nacos主要解决了两个问题，统一配置管理，变更即时生效的问题、分布式服务实例列表管理问题。
如果只有一台计算机，那么程序运行要么是成功的，要么是失败的。服务采用的是单体架构，所有的服务、配置都是在一台计算机上。这种架构的缺点就是：
- 复杂性高
- 容易积累技术债务
- 开发部署效率低
- 扩展能力受限
- 阻断技术创新
如果有台计算机，可能是成百上千台。这个时候每个服务分别部署在不同的计算机上，这个时候就要考虑计算机与计算机之间怎么通信？采用什么通信协议。要考虑多台计算机访问一台计算机的并发问题。计算机 A 调用计算机 B，计算机 B 出错了，怎么保证计算机 A 不受影响，或者降低影响。这里就要考虑计算机A的容错性问题。例如单体架构向微服务架构的转变。
构建一个分布式系统是很难的，需要考虑非常多的问题。而为了解决这些问题产生了很多技术，有传输层面的、存储层面的、计算层面的等等。不过分布式也带来了很多优点：
- 降低系统之间的耦合度
- 增加了可扩展性
- 开发部署更灵活、更方便
- 提高代码的复用性
统一配置管理问题
在单体架构的时候我们可以将配置写在配置文件中，但有一个缺点就是每次修改配置都需要重启服 务才能生效。
当应用程序实例比较少的时候还可以维护。如果转向微服务架构有成百上千个实例，每修改一次配 置要将全部实例重启，不仅增加了系统的不稳定性，也提高了维护的成本。
那么如何能够做到服务不重启就可以修改配置?所有就产生了四个基础诉求:
- 需要支持动态修改配置
- 需要变更实时推送
- 变更后的风险控制，如版本管理、灰度、权限控制等
- 敏感信息的安全配置
Nacos 配置中心分为服务端、客户端、控制台三部分，用户可以通过客户端和控制台进行配置的发布，将配置放到 Nacos服务端进行统一的管理。也可以通过客户端进行配置的监听，当在控制台修改配置时，客户端会实时监听到并做出响应。这样就解决了微服务架构中的配置多、配置难、配置变更等问题。
分布式服务列表管理问题
当我们谈论起服务的实例管理，总要提到注册中心。那么什么是注册中心？注册中心总共有三种角色：
- 服务提供者
- 服务消费者
- 注册中心
注册中心提供服务注册、注销能力。可以让服务提供者将自身或其他服务注册上来，由注册中心进行服务信息的维护，包括服务探活能力、路由功能等。服务提供者可以通过注册中心获取到自身或其他服务的服务信息。
比如有两个服务，服务 A、服务 B，当服务B的服务实例比较少的时候，那么在服务 A 调用服务 B 的时候，我们可以直接在服务 A 中写死 服务 B 的 ip+port。这种方式在服务实例比较少的情况下还能够管理，当服务实例数多了以后，这种方式就没有办法管理了。还要考虑众多 ip 之间的负载、路由问题，当其中的 ip 不可用了，怎么做生命周期管理等。
Nacos 通过自身的注册中心能力解决了服务实例列表管理的问题，提供了如高可用、高性能、水平扩展能力、服务探活能力、路由功能等。
提供了 Springboot、springcloud 项目的接入方式，在服务启动的时候自动将服务实例注册到 Nacos 注册中心，由 Nacos 来管理服务实例，进行服务探活。
Nacos 生态
多语言
Nacos 支持 Java、go、nodejs、c#、c++、python 等多种语言的接入。
Spring 生态
Nacos 无缝支持 Spring 全栈，包括 Spring Cloud、Spring Boot、Spring Framework。
Docker & Kubernetes 生态
nacos-docker 和 nacos-k8s 是 Nacos 开发团队为支持用户容器化衍生的项目。其本质是为了帮助用户方便快捷的通过官方镜像在 Docker 或者 Kubernetes 进行部署。
Service Mesh 生态
Nacos 目前支持 MCP、XDS 两种协议，Istio 可以通过 MCP 协议从 Naocs 获取全量的服务信息列表，在转化成 XDS 协议下发到 envoy。这样就支持了 mesh 化应用内的服务发现。
MCP 协议是 Istio 社区提出的组件之间配置同步协议，这个协议在 1.8 之后就废弃了，替代方案是 MCP over XDS 协议，Nacos 两个协议都兼容。
Nacos 工具
nacos-sync
nacos-sync 是一个支持多种注册中心的同步组件,基于 Spring boot 开发框架,数据层采用 Spring Data JPA ，遵循了标准的 JPA 访问规范，支持多种数据源存储,默认使用 Hibernate 实现。
nacos-ctl
nacos-ctl 是用 Java 开发的命令行工具，包含对命名空间、配置命令、服务命令、实例命令等。
nacosctl
nacosctl 这个项目是我使用 go 语言进行开发的一个命令行工具，纯属造轮子😄。基于 Nacos OpenApi 封装的命令行工具。提供一些对配置、服务注册与发现、命名空间等命令操作 。借助 go 语言的跨平台交叉编译，将编译好的二进制文件直接放到指定系统下就可以直接运行， 无需环境部署。
如果大家想要了解更多的 Nacos 教程，欢迎 star 《On Nacos》开源项目。基于 Nacos 2.x 的入门、原理、源码、实战介绍，帮助开发者快速上手 Nacos。
