目录
一、概览
Nacos是 Dynamic Naming and Configuration Service的首字母简称，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos是阿里开放的一款中间件，它主要提供三种功能：持久化节点注册，非持久化节点注册和配置管理。
二、注册中心基本概念
常用的注册中心：分别为 Zookeeper、Eureka、Nacos、Consul
【最常见的是】zookeeper和eureka，consul用的没那么多，nacos现在用的越来越多，以后也会是一个大的趋势
1) 什么是注册中心？
注册中心的作用一句话概括就是存放和调度服务，实现服务和注册中心，服务和服务之间的相互通信
2) 如果没有注册中心？会怎样
在不用服务注册之前，怎么去维护这种复制的关系网络呢？答案就是：写死。
3) 注册中心主要有三种角色：
-
服务提供者（RPC Server）：在启动时，向 Registry 注册自身服务，并向 Registry 定期发送心跳汇报存活状态。
-
服务消费者（RPC Client）：在启动时，向 Registry 订阅服务，把 Registry 返回的服务节点列表缓存在本地内存中，并与 RPC Sever 建立连接。
-
服务注册中心（Registry）：用于保存 RPC Server 的注册信息，当 RPC Server 节点发生变更时，Registry 会同步变更，RPC Client 感知后会刷新本地 内存中缓存的服务节点列表。
4) 服务注册中心的作用
- 服务注册，就是将提供某个服务的模块信息(通常是这个服务的ip和端口)注册到1个公共的组件上去（比如: zookeeper\consul）。
- 服务发现，就是新注册的这个服务模块能够及时的被其他调用者发现。不管是服务新增和服务删减都能实现自动发现。
5）CAP 理论
CAP 理论是分布式架构中重要理论：
-
一致性(Consistency)：所有节点在同一时间具有相同的数据；
-
可用性(Availability) ：保证每个请求不管成功或者失败都有响应；
-
分隔容忍(Partition tolerance) ：系统中任意信息的丢失或失败不会影响系统的继续运作。
关于 P 的理解，我觉得是在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用，而可用性是，某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求。
CAP 不可能都取，只能取其中两个的原因如下：
-
如果 C 是第一需求的话，那么会影响 A 的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，期间可用性就会降低。
-
如果 A 是第一需求，那么只要有一个服务在，就能正常接受请求，但是对于返回结果变不能保证，原因是，在分布式部署的时候，数据一致的过程不可能想切线路那么快。
-
再如果，同时满足一致性和可用性，那么分区容错就很难保证了，也就是单点，也是分布式的基本核心。
6）CP和AP的选择
服务注册中心选型对比的时候，其他的分布式系统选型的时候，CP，AP
P简单来说就是任何分布式系统一般都会满足，他就是分区容错性；
CP：C，一致性，尽可能的去保证你读取到的数据是一致的，牺牲掉一个A可用性，一旦leader崩溃，【崩溃的时候可能不同的Follower数据是不一致的】zk可能会有一个短时间内，几十s有可能，集群不可用，此时需要重新选举一个leader，然后再做数据同步，保证数据一致性之后再开放让你来读取
【CP就是Leader崩溃后牺牲可用性，牺牲可用性A】
三、什么是 Nacos？
Nacos 支持几乎所有主流类型的服务的发现、配置和服务管理平台，提供「注册中心」、「配置中心」和「动态 DNS 服务」三大功能。能够无缝对接Springcloud、Spring、Dubbo等流行框架。
| 功能模块 | nacos | eureka | 功能说明 |
| 注册中心 | √ | √ | 服务治理，服务中心化注册 |
| 配置中心 | √ | × | eureka需要配合springcloud config实现 |
| 配置动态刷新 | √ | × | nacos通过netty保持tcp长链接进行推送，eureka需要配合mq实现配置动态刷新 |
| 可用区az | √ | √ | 对服务集群划分不同区域，实现区域隔离，并提供灾难级自动切换 |
| 分组 | √ | × | nacos根据不同的业务、环境进行分组管理（namespace,group |
| 元数据 | √ | √ | 提供服务标签数据（环境、服务标识） |
| 权重 | √ | × | nacos提供权重设置，调整承载流量压力 |
| 健康检查 | √ | √ | nacos提供服务端或者客户端发起的健康监测，eureka是有客户端发起心跳 |
| 负载均衡 | √ | √ | 均提供负载均衡策略，eureka采用ribbon |
| Nacos | Eureka | Consul | CoreDNS | Zookeeper | |
| 一致性协议 | CP+AP | AP | CP | — | CP |
| 健康检查 | TCP/HTTP/MYSQL/Client Beat | Client Beat | TCP/HTTP/gRPC/Cmd | — | Keep Alive |
| 负载均衡策略 | 权重/metadata/Selector | Ribbon | Fabio | RoundRobin | — |
| 雪崩保护 | 有 | 有 | 无 | 无 | 无 |
| 自动注销实例 | 支持 | 支持 | 不支持 | 不支持 | 支持 |
| 访问协议 | HTTP/DNS | HTTP | HTTP/DNS | DNS | TCP |
| 监听支持 | 支持 | 支持 | 支持 | 不支持 | 支持 |
| 多数据中心 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| 跨注册中心同步 | 支持 | 不支持 | 支持 | 不支持 | 不支持 |
| SpringCloud集成 | 支持 | 支持 | 支持 | 不支持 | 支持 |
| Dubbo集成 | 支持 | 不支持 | 不支持 | 不支持 | 支持 |
| K8S集成 | 支持 | 不支持 | 支持 | 支持 | 不支持 |
四、Nacos 的关键特性，nacos能做什么？
1）服务发现和服务健康监测
Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用 原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。
Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。 对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。
2）动态配置服务
动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。
配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。
Nacos 提供了一个简洁易用的UI (控制台样例 Demo) 帮助您管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。
3）动态 DNS 服务
动态 DNS 服务支持权重路由，让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。
Nacos 提供了一些简单的 DNS APIs TODO 帮助您管理服务的关联域名和可用的 IP:PORT 列表.
4）服务及其元数据管理
Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。
五、为什么需要Nacos
在软件发展初期，企业还是传统的单体应用架构，将所有的功能都打包成一个应用服务进行部署。随着业务体系的不断发展扩大，单体应用架构的弊端日益显现。
如果可以把一个大的应用服务按照不同的维度和领域拆分成若干个子服务，各个业务团队只需要专注于自身负责的服务，各自进行开发部署迭代，不相互影响，那该多好。因此，传统的单元应用架构开始朝着微服务架构方向演进。演进过程中首要问题就是微服务如何相互发现对方进行调用？我们将这种相互发现、相互调用的能力称之为微服务注册发现。Nacos就具备这种微服务注册发现能力。
作为当前主流的服务注册发现配置中心之一，Nacos已经成为了国内开发者的首选，有着广泛的群众基础。
CSE服务注册发现配置中心引擎service-center目前支持SpringCloud Huawei、ServiceComb微服务框架，而当前国内主流框架是基于SpringCloud Alibaba、Dubbo等，这些框架集成了Nacos作为注册发现配置中心。
为了拥抱开源体系的注册发现配置中心，提高CSE的竞争力，吸引更多的用户，CSE新增了支持托管Nacos集群的特性。
六、Nacos架构
- 特性大图：要从功能特性，非功能特性，全面介绍我们要解的问题域的特性诉求
- 架构大图：通过清晰架构，让您快速进入 Nacos 世界
- 业务大图：利用当前特性可以支持的业务场景，及其最佳实践
- 生态大图：系统梳理 Nacos 和主流技术生态的关系
- 优势大图：展示 Nacos 核心竞争力
- 战略大图：要从战略到战术层面讲 Nacos 的宏观优势
1）心跳检测
Nacos的心跳检测比较有特色。常规的心跳检测方式有两种，一种是客户端主动上报，服务端一段时间未收到心跳就会将客户端下线。另一种是服务端主动去调客户端的心跳接口，如果没有得到正常响应或者超时就将客户端下线。
在注册中心的场景中，客户端的数量一定是会远多于服务端的，如果让服务端去主动轮询心跳接口，会给服务端比较大的压力，所以目前的主流选择都是让客户端去主动上报。
但是Nacos对临时节点和永久节点分别做了处理，如果是临时节点，那么就需要临时节点主动上报，如果是永久节点，Nacos可以主动发起TCP端口检查或者是HTTP接口检查，用来做健康检查。
在Nacos的定义中，临时节点都是弹性扩容之后注册的，随着访问量下来，相关服务是会被回收的，而有的永久节点是无法发起健康检查的，例如一些三方服务，只能提供出一个接口用于心跳检查。
2）配置中心原理
客户端启动后，每30秒给Server发送一个心跳包，Server拿到心跳包之后，先对比一下数据版本，如果版本一样说明数据没有变化，这时Server不会立即将该心跳返回，Server会一直拿着这个心跳，此时和客户端保持长连接的状态，直到数据有变化或者持有超过29.5秒，如果客户端感知到数据版本发生变化，就会主动请求Server拉取数据。
阿里出品的中间件都有个特点，不像一个纯粹的中间件，更像是业务锤炼出来的产物，在RocketMQ，Nacos上这种味道特别明显，它总是会考虑非常多的业务场景，在性能与好用性方面做一个取舍，使用阿里中间件的最大感受就是：它也许不是性能最好的，也许不是纯粹的，但是一定是最适合拿来做业务的。
来源地址：https://blog.csdn.net/qq_20957669/article/details/128939241
