Alibaba-Nacos

简介

解决微服务中的统一配置、服务注册于发现等问题。帮助开发者快速实现动态服务发现、服务配置、服务元数据及流量管理。

关键特性

• 服务发现和健康检测

  • 支持基于DNS和基于RPC的服务发现。

    • 提供者：使用原生SDK、OpenAPI或一个独立的 Agent TODO 注册Service；

    • 消费者：使用DNS或HTTP&API查找和发现服务；

  • Nacos提供对服务实时的健康检查，阻止向不健康的主机或服务实例发送请求。

• 动态配置服务

• 动态DNS服务

  • 支持权重路由，让开发者更容易地实现中间层负载均衡、更灵活的路由策略、流量控制，以及数据中心内网的简单DNS解析服务；

• 服务及元数据管理

Nacos的实现原理

服务提供者通过VIP(Vritual IP)访问Nacos Server 高可用集群，基于Open API完成服务的注册和服务的查询。

Nacos Server本身可以支持主备模式，所以底层会采用数据一致性算法来完成从节点的数据同步。

服务消费者也是如此，基于Open API 从Nacos Server 中查询服务列表；

 

注册中心的原理

• 服务实例在启动时注册到服务注册表中，并在关闭时注销；

• 服务消费者查询服务注册表，获得可用实例；

• 服务注册中心需要调用服务实例的健康检查API来验证它是否能够处理请求

Nacos Config实现原理

1. 获取配置：从Nacos Config Server中读取配置；

2. 监听配置：订阅感兴趣的配置，当配置发生变化时可以收到一个事件；

3. 发布配置：讲配置保存到Nacos Config Server中；

4. 删除配置：删除配置中心的指定配置。

动态监听

常用的方式有两种：

• Pull：表示客户端从服务端主动拉取数据；

• Push：表示服务端主动把数据推送给客户端；

Nacos采用的是Pull模式，并且是长轮询机制，它结合了Push和Pull两者的优势。

客户端采用长轮询方式发起Pull请求，去检查服务端配置信息是否发生了变化，如果发生了变更，则客户端会根据变更的数据获得最新的配置。简单来说，客户端发起请求，服务端如果没有变动就保持连接，如果有变动再返回。

Data ID

${application.name}-${spring.profiles.active}.${file-extension}

算法：

Nacos采用Raft算法来保证集群部署的高可用；

Raft算法

目的就是解决一致性问题

• leader选举

  • 启动的时候进行选举；

  • leader节点挂了之后进行选举；

  • 节点重新上线；

• 数据的一致性同步

  • 保证集群节点中所有节点的数据一致性

节点状态

• Leader：领导

• Follower：节点

• Candidate：候选人

当要增删改数据时，如果发送到follower节点时，follower节点会转发给leader节点；

leader节点采用2pc方式，先广播到其他节点，收到后给leader一个回值，如果大于过半节点时，则发送写入；

选举

1. 0-15000ms内随机生成一个值，再减 500ms；例如：15000ms 要执行30次

2. 如果大于0还没办法选举，只有小于才会发起投票；

3. 重置，重新leader选举间隔时间

4. 重置，重新心跳时间；

5. 发起投票

• • 重置

  • 增加term值

  • 投自己

每个节点选举时间不一样，都在150-300ms之间，谁先走完先投自己，并传播给他节点，如果其他节点时间没走完，则赞同当前投票；

当第一个节点收到过半时，则建立leader，并与其他节点建立心跳；

脑裂恢复后，以term大的为准；

term：选举或者数据同步会增加；