RuaaaHaHa的博客

配置数据，是直接在 Nacos 服务端进行创建并进行管理的，必须保证大部分的节点都保存了此配置数据才能认为配置被成功保存了，否则就会丢失配置的变更，如果出现这种情况，问题是很严重的，如果是发布重要配置变更出现了丢失变更动作的情况，那多半就要引起严重的现网故障了，因此对于配置数据的管理，是必须要求集群中大部分的节点是强一致的，而这里的话只能使用。作为一种有状态的中间件应用的内嵌协议，Distro保证了各个Nacos节点对于海量注册请求的统一协调和存储。，通过算法来保障各个节点之间的数据的一致性。

可以想象下，当你新增一个 Nacos 节点时，需要去手动修改每个 Nacos 节点下的 cluster.conf 文件，这是多么辛苦的一件工作，或者稍微高端一点，利用 ansible 等自动化部署的工具去推送 cluster.conf 文件去代替自己的手动操作，虽然说省去了较为繁琐的人工操作步骤，但是仍旧存在一个问题——每一个 Nacos 节点都存在一份 cluster.conf 文件，当 Nacos节点启动时，会读取该文件的内容，然后将文件内的 IP 解析为节点列表，调用。的内容信息，这样，运维人员。

(当前实现版本)人工管控方案：集群视角的系统负载控制台，提供连接数，负载等视图(扩展新增连接数，负载，CPU 等信息，集群间 report 同步)，实现人工调节每个 Server 节点的连接数，人工触发reblance，人工削峰填谷。(未来终态版本)自动化管控方案：基于每个 server 间连接数及负载自动计算节点合理连接数，自动触发reblance，自动削峰填谷。核心的策略是客户端+服务端双向调节策略，客户端随机选择+服务端运行时柔性调整。，http 短连接性能压力巨大，未来 Nacos 需要。

这种健康检查方式的多样性非常重要，这样可以支持各种类型的服务，让这些服务都可以使用到Nacos的负载均衡能力。使用心跳上报方式维持活性，发送心跳的周期默认是5秒，Nacos服务端会在15秒没收心跳后将实例设置为不健康，在30秒没收到心跳时将这个临时实例摘除。Nacos试图做的是将服务端负载均衡与客户端负载均衡通过某种机制结合起来，提供用户扩展性，并给予用户充分的自主选择权和轻便的使用方式。Nacos目前的一致性协议实现，一个是基于简化的Raft的CP一致性，一个是基于自研协议的Distro的AP一致性。

命名空间（Namespace）：Nacos 数据模型中最顶层、也是包含范围最广的概念，用于在类似环境或租户等需要强制隔离的场景中定义。Nacos 的服务也需要使用命名空间来进行隔离。分组（Group）：Nacos 数据模型中次于命名空间的一种隔离概念，区别于命名空间的强制隔离属性，分组属于一个弱隔离概念，主要用于逻辑区分一些服务使用场景或不同应用的同名服务，最常用的情况主要是同一个服务的测试分组和生产分组、或者将应用名作为分组以防止不同应用提供的服务重名。服务名（Name）

由于持久化服务的实例的在被主动删除前一直存在的特性，探活的定时任务会不断探测服务的健康状态，并且将无法探测成功的实例标记为不健康。但是有些时候会有这样的场景，有些服务不希望去校验其健康状态，**Nacos也是提供了对应的白名单配置，用户可以将服务配置到该白名单，那么 Nacos 会放弃对其进行健康检查，**实例的健康状态也始终为用户传入的健康状态。临时实例只会对其被负责的注册中心节点发送心跳信息，注册中心服务节点会对其负责的永久实例进行健康探测，在。进行临时实例的注册，通过 Nacos 的。