【Nacos架构 & 原理】服务发现模块之Nacos注册中心的设计原理

数据模型

注册中心的核心数据是服务的名字（通常是唯一标识一个服务的字符串）和它对应的网络地址（可以是IP地址加端口号，或者是更复杂的URI）。当一个服务需要与另一个服务通信时，它可以查询注册中心，通过服务名获取到对应的网络地址，然后直接与目标服务进行通信。
更多的场景：

• 当服务注册了多个实例时，需要对不健康的实例进行过滤或者针对实例的一些特征进行流量的分配，所以需要再实例上存储一些例如**健康状态、权重等属性。
• 随着服务规模的扩大，需要在整个服务级别设定一些权限规则、以及对所有实例都生效的开关，由此又需要再服务级别设立一些额外的属性。
• 单个服务的实例会划分为多个子集的需求，例如一个服务是多机房部署的，可能需要对每个机房的实例做不同的配置，这样又需要在服务和实例之间再设定一个数据级别。
  服务-集群-实例的三层模型：
  
  这样基本可以满足服务在所有场景下的数据存储和管理
  服务的逻辑隔离模型：
  作为一个共享服务型的组件，需要能够在多个用户或者业务方使用的情况下，保证数据的隔离和安全。
  
  Nacos提供了四层的数据逻辑隔离模型。
  用户账号（上图中的Company）：对应的可能是一个企业或者独立的个体，这个账户通常用于管理权限和访问控制，但它的信息不会直接存储或传递到服务注册中。
  命名空间（Namespace）：用户账户可以创建多个命名空间，每个命名空间相当于一个隔离的环境或者作用域。在实际应用中允许同一个用户账号管理不同的项目或环境（如生产环境、测试环境等），每个环境下可以有独立的服务集合。
  物理集群：注册中心的物理集群是实际运行注册中心服务的服务器群。为了提高可用性和扩展性，一个注册中心可能由多个这样的物理集群组成。
  路由规则：当客户端实例（代表命名空间内的服务集合）尝试注册或者发现服务的时候，会被路由到适当的注册中心物理集群，这个路由过程是基于预定义规则自动进行的，确保了高效的服务管理和负载均衡。
  这样的物理集群和路由规则使得Nacos能够实现无感知升级与迁移（用户不需要关心后端的变化），因为命名空间到物理集群的映射和路由是由注册中心自动管理的，用户的服务发现和注册流程不受影响。

数据一致性

Nacos目前的一致性协议实现，一个是基于简化的Raft的CP一致性，一个是基于自研协议的Distro的AP一致性。

负载均衡

Nacos定义了Selector，作为负载均衡的统一抽象。
Nacos试图做的是将服务端负载均衡与客户端负载均衡通过某种机制结合起来，提供用户扩展性，并给予用户充分的自主选择权和轻便的使用方式。

健康检查

Nacos目前支持临时实例使用心跳上报方式维持活性，发送心跳的周期默认是5秒，Nacos服务端会在15秒没收心跳后将实例设置为不健康，在30秒没收到心跳时将这个临时实例摘除。
客户端健康检查和服务端健康检查有一些不同的关注点。
客户端健康检查：主要关注客户端上报心跳的方式，服务端摘除不健康客户端的机制。
服务端健康检查：关注探测客户端的方式、灵敏度及设置客户端健康状态的机制。
Nacos既支持客户端的健康检查，也支持服务端的健康检查，同一个服务可以切换健康检查模式。这种健康检查方式的多样性非常重要，这样可以支持各种类型的服务，让这些服务都可以使用到Nacos的负载均衡能力。

性能与容量

易用性

集群扩展性

用户扩展性