Nacos基础分享

最新推荐文章于 2024-08-27 19:57:27 发布

青鱼入云

最新推荐文章于 2024-08-27 19:57:27 发布

阅读量952

点赞数 28

分类专栏：架构文章标签：架构

本文链接：https://blog.csdn.net/u011305680/article/details/141129473

版权

架构专栏收录该内容

10 篇文章 0 订阅

订阅专栏

Distro 协议-nacos自研最终一致性协议

简介

官方定义

Nacos（Naming and Configuration Service）：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

动态服务发现：对以服务为中心的（例如微服务和云原生）应用架构方式非常关键。Nacos 支持 DNS-Based 和 RPC-Based（Dubbo、gRPC）模式的服务发现。Nacos 也提供实时健康检查，以防止将请求发往不健康的主机或服务实例。借助 Nacos，您可以更容易地为您的服务实现断路器。
动态配置服务：让您能够以中心化、外部化和动态化的方式管理所有环境的配置。动态配置消除了配置变更时重新部署应用和服务的需要。配置中心化管理让实现无状态服务更简单，也让按需弹性扩展服务更容易。
服务管理：通过支持权重路由，动态 DNS 服务能让您轻松实现中间层负载均衡、更灵活的路由策略、流量控制以及简单数据中心内网的简单 DNS 解析服务。动态 DNS 服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以消除耦合到厂商私有服务发现 API 上的风险。

诞生历史

Nacos 在阿里巴巴起源于 2008 年五彩石项目（完成微服务拆分和业务中台建设）。随着云计算兴起，2018 年受到开源软件行业的影响，因此决定将 Nacos（阿里内部 Configserver 非持久注册中心，VIPServer 持久化注册中心，Diamond 配置中心作为内核）开源。

竞品介绍

ZooKeeper、Eureka、Consul 、Nacos微服务注册中心对比

ACM、Diamond、Nacos、Apollo、Spring Cloud Config

业务术语

名词	解释
Namespace （命名空间）	命名空间通过提供一种机制来组织和管理标识符（如变量名、函数名、类名等），使得具有相同名称的标识符在不同的命名空间中可以共存，从而避免了全局命名空间的冲突问题。
推空保护	客户端在请求注册中心订阅服务端地址列表时，有可能出现服务端注册异常的场景，注册中心返回了空列表，此时客户端忽略该空返回的变更，从缓存中获取上一次正常的服务端地址进行服务访问。
配置快照	Nacos 的客户端 SDK 会在本地生成配置的快照。当客户端无法连接到 Nacos Server 时，可以使用配置快照显示系统的整体容灾能力。配置快照类似于 Git 中的本地 commit，也类似于缓存，会在适当的时机更新，但是并没有缓存过期（expiration）的概念。

服务注册&配置中心使用教程

一、Spring Cloud Alibaba 之 Nacos - 掘金 (juejin.cn)

MSE管理控制台 (aliyun.com)

dubbo-registry-nacos.jar

spring-cloud-starter-alibaba-nacos-config.jar

bootstrap.yml

application.yml

AppConfig

Nacos配置模型

基础模型

上图是 Nacos 配置管理的基础模型：

Nacos 提供可视化的控制台，可以对配置进行发布、更新、删除、灰度、版本管理等功能。
SDK 可以提供发布配置、更新配置、监听配置等功能。
SDK 通过 GRPC 长连接监听配置变更，Server 端对比 Client 端配置的 MD5 和本地 MD5 是否相等，不相等推送配置变更。
SDK会保存配置的快照，当服务端出现问题的时候从本地获取。

配置资源模型

Namespace 的设计就是用来进行资源隔离的，我们在进行配置资源的时候可以从以下两个角度来看：

从单个租户的角度来看，我们要配置多套环境的配置，可以根据不同的环境来创建 Namespace 。比如开发环境、测试环境、线上环境，我们就创建对应的 Namespace（dev、test、prod），Nacos 会自动生成对应的 Namespace Id 。如果同一个环境内想配置相同的配置，可以通过 Group 来区分。如下图所示：

从多个租户的角度来看，每个租户都可以有自己的命名空间。我们可以为每个用户创建一个命名空间，并给用户分配对应的权限，比如多个租户（zhangsan、lisi、wangwu），每个租户都想有一套自己的多环境配置，也就是每个租户都想配置多套环境。那么可以给每个租户创建一个 Namespace （zhangsan、lisi、wangwu）。同样会生成对应的 Namespace Id。然后使用 Group 来区分不同环境的配置。如下图所示：

Nacos注册中心原理

数据模型

负载均衡

客户端负载均衡

服务端负载均衡

服务端的负载均衡，给服务提供者更强的流量控制权，但是无法满足不同的消费者希望使用不同负载均衡策略的需求。而不同负载均衡策略的场景，确实是存在的。而客户端的负载均衡则提供了这种灵活性，并对用户扩展提供更加友好的支持。但是客户端负载均衡策略如果配置不当，可能会导致服务提供者出现热点，或者压根就拿不到任何服务提供者。

健康检查

客户端健康检查和服务端健康检查有一些不同的关注点。客户端健康检查主要关注客户端上报心跳的方式、服务端摘除不健康客户端的机制。而服务端健康检查，则关注探测客户端的方式、灵敏度及设置客户端健康状态的机制。

性能与容量

Nacos的一致性协议

Raft（CP）：保障配置数据和持久化服务注册发现。配置数据，是直接在 Nacos 服务端进行创建并进行管理的，必须保证大部分的节点都保存了此配置数据才能认为配置被成功保存了，否则就会丢失配置的变更；服务发现注册中的持久化服务，因为所有的数据都是直接使用调用Nacos服务端直接创建，因此需要由Nacos保障数据在各个节点之间的强一致性，故而针对此类型的服务数据，选择了强一致性共识算法来保障数据的一致性。

Distro（AP）：服务发现注册中心，在当前微服务体系下，是十分重要的组件，服务之间感知对方服务的当前可正常提供服务的实例信息，必须从服务发现注册中心进行获取，因此对于服务注册发现中心组件的可用性，提出了很高的要求，需要在任何场景下，尽最大可能保证服务注册发现能力可以对外提供服务；同时 Nacos 的服务注册发现设计，采取了心跳可自动完成服务数据补偿的机制。如果数据丢失的话，是可以通过该机制快速弥补数据丢失。

Distro 协议-nacos自研最终一致性协议

Distro 协议是 Nacos 对于临时实例数据开发的一致性协议。其数据存储在缓存中，并且会在启动时进行全量数据同步，并定期进行数据校验。
在 Distro 协议的设计思想下，每个 Distro 节点都可以接收到读写请求。所有的 Distro 协议的请求场景主要分为三种情况：
1、当该节点接收到属于该节点负责的实例的写请求时，直接写入。
2、当该节点接收到不属于该节点负责的实例的写请求时，将在集群内部路由，转发给对应的节点，从而完成读写。
3、当该节点接收到任何读请求时，都直接在本机查询并返回（因为所有实例都被同步到了每台机器上）。
Distro 协议作为 Nacos 的内嵌临时实例一致性协议，保证了在分布式环境下每个节点上面的服务信息的状态都能够及时地通知其他节点，可以维持数十万量级服务实例的存储和一致性。