Nacos是阿里的一个开源产品，是针对微服务架构中的服务发现、配置管理、服务治理的综合型解决方案。

（用来实现配置中心和服务注册中心）

服务发现和服务健康监测（使服务更容易注册，并通过DNS或HTTP接口发现其他服务，还提供服务的实时健康检查，以防 止向不健康的主机或服务实例发送请求。 ）

支持基于DNS和基于RPC的服务发现。服务提供者使用原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。

Nacos提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。 对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。

动态配置服务：

以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。

消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。

配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。

提供了一个简洁易用的UI (控制台样例 Demo) 帮助管理所有的服务和应用的配置。

Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，能更安全地在生产环境中管理配置变更和降低配置变更带来的风险。

动态 DNS 服务支持权重路由，更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能更容易地实现以 DNS 协议为基础的服务发现，消除耦合到厂商私有服务发现 API 上的风险。

Nacos 提供了一些简单的 DNS APIs TODO ，管理服务的关联域名和可用的 IP:PORT 列表

服务及其元数据管理

从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。

在微服务架构中一个业务流程需要多个微服务通过网络接口调用完成业务处理，服务消费方从服务注册中心获取服 务提供方的地址，从而进行远程调用，这个过程叫做服务发现。

服务发现过程

在微服务架构中，整个系统会按职责能力划分为多个服务，通过服务之间协作来实现业务目标。服务的消费方要调用服务的生产方，为了完成一次请求，消费方需要知道服务生产方的网络位置(IP地址和端口号)。

微服务可能是部署在云环境的，服务实例的网络位置或许是动态分配的。

每个服务一般会有多个实例来做负载均衡，由于宕机或升级，服务实例网络地址会经常动态改变。每个服务也可能应对临时访问压力增加新的服务节点。

服务发现概念

服务发现就是服务消费方通过服务发现中心智能发现服务提供方，从而进行远程调用的过程。服务实例本身并不记录服务生产方的网络地址，所有服务实例内部都会包含服务发现客户端。

在每个服务启动时会向服务发现中心上报自己的网络位置。在服务发现中心内部会形成一个服务注册表，服务注册表是服务发现的核心部分，是包含所有服务实例的网络地址的数据库。

服务发现客户端会定期从服务发现中心同步服务注册表 ，并缓存在客户端。

当需要对某服务进行请求时，服务实例通过该注册表，定位目标服务网络地址。若目标服务存在多个网络地址，则使用负载均衡算法从多个服务实例中选择出一个，然后发出请求。

服务发现产品对比

目前市面上用的比较多的服务发现中心有：Nacos、Eureka、Consul和Zookeeper。

负载均衡功能

在RESTful服务发现的流程中，ServiceA通过负载均衡调用ServiceB；

负载均衡就是将用户请求（流量）通过一定的策略，分摊在多个服务实例上执行，它是系统处理高并发、缓解网络压力和进行服务端扩容的重要手段之一。

它分为服务端负载均衡和客户端负载均衡。

服务器端负载均衡：

在负载均衡器中维护一个可用的服务实例清单，当客户端请求时，负载均衡服务器按照某种配置好的规则(负载均衡算法)从可用服务实例清单中选取其一去处理客户端的请求。这就是服务端负载均衡。

例如Nginx，通过Nginx进行负载均衡，客户端发送请求至Nginx，Nginx通过负载均衡算法，在多个服务器 之间选择一个进行访问。即在服务器端再进行负载均衡算法分配。

上边使用的LoadBalancerClient就是一个客户端负载均衡器，具体使用的是Ribbon客户端负载均衡器。 Ribbon在发送请求前通过负载均衡算法选择一个服务实例，然后进行访问，这是客户端负载均衡。即在客户端就进行负载均衡的分配。

Ribbon是一个客户端负载均衡器，其责任是从一组实例列表中挑选合适的实例，如何挑选，取决于负载均衡策略 。

Ribbon核心组件IRule是负载均衡策略接口，实现：

RoundRobinRule(默认)：轮询，即按一定的顺序轮换获取实例的地址；

RandomRule:随机，即以随机的方式获取实例的地址；

AvailabilityFilteringRule：会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,以及并发的连接数量超过阈值的服务,然后对剩余的服务列表按照轮询策略进行访问；

WeightedResponseTimeRule：根据平均响应时间计算所有服务的权重，响应时间越快，服务权重越大,被选中的机率越高；刚启动时,如果统计信息不足,则使用RoundRobinRule策略，等统计信息足够时,会切换到 WeightedResponseTimeRule；

RetryRule：先按照RoundRobinRule的策略获取服务,如果获取服务失败，则在指定时间内会进行重试，获取可用的服务；

BestAvailableRule: 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,然后选择一个并发量最小的服务；

ZoneAvoidanceRule：默认规则，复合判断server所在区域的性能和server的可用性选择服务器;

Nacos配置管理

配置中心

在微服务架构中为了统一管理各微服务的配置信息专门设置配置中心，配置中心就是一种统一管理各种应用配置的基础服务组件。

配置应用程序在启动和运行的时候往往需要读取一些配置信息，配置基本上伴随着应用程序的整个生命周期，比如：数据库连接参数、启动参数等。

配置特点：

配置是独立于程序的只读变量。配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置

配置贯穿于应用的整个生命周期。应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。 如：启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。

配置可以有多种加载方式。常见的有程序内部hard code，配置文件，环境变量，启动参数，基于数据库等

配置需要治理。同一份程序在不同的环境（开发，测试，生产）、不同的集群（如不同的数据中心）经常需要有不同的 配置，所以需要有完善的环境、集群配置管理

配置中心

微服务架构中，当系统从一个单体应用，被拆分成分布式系统上一个个服务节点后，配置文件也必须跟着迁移 （分割），这样配置就分散了，同时分散中还包含着冗余

配置管理模型

对于Nacos配置管理，通过Namespace、group、Data ID能够定位到一个配置集。

配置集(Data ID)：

在系统中，一个配置文件通常就是一个配置集，一个配置集可以包含了系统的各种配置信息，如：一个配置集可能包含了数据源、线程池、日志级别等配置项。每个配置集都可以定义一个有意义的名称，就是配置集的ID即Data ID。

配置项：

配置集中包含的一个个配置内容就是配置项。它代表一个具体的可配置的参数与其值域，通常以 key=value 的形式存在。如我们常配置系统的日志输出级别（logLevel=INFO|WARN|ERROR） 就是一个配置项。

配置分组(Group)：

配置分组是对配置集进行分组，通过一个有意义的字符串（如 Buy 或 Trade ）来表示，不同的配置分组下可以有相同的配置集（Data ID）。当在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用DEFAULT_GROUP 。配置分组的常见场景：可用于区分不同的项目或应用，例如：学生管理系统的配置集可以定义一个group为：STUDENT_GROUP。

命名空间(Namespace)：

命名空间可用于进行不同环境的配置隔离。例如可以隔离开发环境、测试环境和生产环境，因为 它们的配置可能各不相同，或者是隔离不同的用户，不同的开发人员使用同一个nacos管理各自的配置，可通过 namespace隔离。不同的命名空间下，可以存在相同名称的配置分组(Group) 或 配置集。