

Spring Cloud Alibaba 微服务框架 Nacos：微服务注册中心和配置中心

首页  思维导图  详情



Spring Cloud Alibaba 微服务框架 Nacos：微服务注册中心和配置中心

2022-05-21 12:08:52   0  举报





AI智能生成

Spring Cloud Alibaba 微服务框架 Nacos 微服务注册中心和配置中心

Spring Cloud

Spring Cloud Alibaba

Nacos

注册中心

配置中心

模版推荐

作者其他创作

大纲/内容

Nacos之注册中心

注册中心

服务地址的管理

服务注册

服务动态感知

架构图

图片

Provider：服务提供者

Consumer：服务消费者

Name Server：通过VIP（Vritual IP）或者DNS的方式实现Nacos高可用集群的服务路由

Nacos Server：Nacos服务提供者

Open API

Config Service

Naming Service

Consistency Protocol：用来实现Nacos集群节点的数据同步，这里使用的是Raft算法

Nacos Console

关键特性

服务发现和服务健康监测

Nacos支持基于DNS和基于RPC的服务发现。服务提供者使用原生SDK、OpenAPI或一个独立的Agent TODO注册Service后，服务消费者可以使用DNS或HTTP&API查找和发现服务。

Nacos提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。 Nacos支持传输层（PING或TCP）和应用层（如HTTP、MySQL、用户自定义）的健康检查。

Nacos提供了agent上报和服务端主动检测两种健康检查模式。

Nacos提供了统一的健康检查仪表盘，帮助用户根据健康状态管理服务的可用性及流量。

动态配置服务

动态配置服务可以以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置，可以使配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。

还提供了包括配置版本跟踪、金丝雀发布、一键回滚配置及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助用户更安全地在生产环境中管理配置变更，降低配置变更带来的风险。

提供了一个简洁易用的UI帮助用户管理所有服务和应用的配置

动态DNS服务

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

服务及其元数据管理

Nacos可以使开发者从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策

部署模式

单机：用于测试和单机试用

集群：用于生产环境，确保高可用

部署架构图

图片

部署说明

http://ip1:port/openAPI 直连ip模式，机器挂则需要修改ip才可以使用

http://VIP:port/openAPI 挂载VIP模式，直连vip即可，下面挂server真实ip，可读性不好

http://nacos.com:port/openAPI 域名 + VIP模式，可读性好，而且换ip方便，推荐模式

部署步骤

环境准备

下载源码或者安装包

配置集群配置文件

在nacos的解压目录nacos/的conf目录下

有配置文件cluster.conf，请每行配置成ip:port

请配置3个或3个以上节点

确定数据源

使用内置数据源

无需进行任何配置

使用外置数据源

初始化 MySQL 数据库

application.properties 配置

启动服务器

独立模式

集群模式

使用内置数据源

使用外置数据源

多集群：用于多数据中心场景

图片

解决方案：使用Nacos-Sync 组件来做数据中心之间的数据同步

数据模型

Nacos数据模型

图片

Nacos服务分级存储模型

图片

Nacos配置实体模型

图片

API说明

Nacos提供了SDK及Open API的方式来完成服务注册与发现等操作，由于服务端只提供了REST接口，所以SDK本质上是对于HTTP请求的封装

通过＠NacosInjected注入Nacos的NamingService，并提供discovery方法，可以根据服务名称获得注册到Nacos上的服务地址。

服务实例

临时实例

使用客户端上报模式进行健康检查

临时实例需要nacos能够自动摘除不健康实例，而且无需持久化存储实例，那么这种实例就适用于类 Gossip 的协议

持久化实例

使用服务端反向探测模式进行健康检查

因为客户端不会上报心跳，nacos不能自动摘除下线的实例

相关中间件对比

eureka

eureka是一个AP的服务注册中心

任何一个Eureka Server都是独立的，可存储所有的服务注册信息

即使任意一台Eureka Server宕机，其余的机器都可以照常工作

保证高可用性，但是不保证数据是一致的

zookeeper

zookeeper是一个CP的服务注册中心

所有的服务注册信息都存储在leader的机器上，同步给其他的follewer

若leader宕机，则不能提供服务注册的功能了，需要重新选举

保证强一致性，无法保证高可用性

nacos

nacos在 1.0.0 正式支持 AP 和 CP 两种一致性协议并存

一个是基于简化的 Raft 的 CP 一致性，一个是基于自研协议 Distro 的 AP 一致性

Raft 协议基于 Leader 进行写入，其 CP 也并不是严格的，只是能保证一半所见一致，以及数据的丢失概率较小

Distro 协议则是参考了内部 ConfigServer 和开源 Eureka，在不借助第三方存储的情况下，实现基本大同小异

其他

Eureka不能支持大量的服务实例的原因

eureka所有的服务实例在每一台Eureka Server中都保存了

大量的服务实例会产生大量的心跳检测等信息，导致Eureka Server无法支持高并发的操作

Zookeeper不能支持大量的服务实例的原因

zookeeper会将服务实例的上线下线通知到每一个服务实例

如果频繁的上下线的话，会去通知大量的服务实例，导致短时间网络压力增大，性能下降

参考资料

Nacos 注册中心的设计原理详解

Nacos 注册配置中心介绍

Nacos 服务注册与发现原理分析

Nacos之配置中心

本地配置方式的不足

配置的动态更新：在实际应用中会有动态更新配置的需求，在传统模式下，需要手动修改配置文件并且重启应用才能生效，这种方式效率太低，重启也会导致服务暂时不可用

配置集中式管理：微服务架构中部署的节点很多，一旦配置文件中的某个属性需要修改，本地配置的方式修改工作量是巨大的

配置内容的安全性和权限：配置文件随着源代码统一提交到代码库中，容易造成生产环境配置信息的数据泄露

不同部署环境下配置的管理：通过profile机制来管理不同环境下的配置，这种方式对于日常维护来说比较烦琐

Nacos集成Spring Boot 实现统一配置管理

添加Nacos Config的spring-boot-starter依赖

在application.properties中添加Nacos Server的地址

创建NacosConfigController类，用于从Nacos Server动态读取配置

Nacos读取配置的两个注解说明

＠NacosPropertySource：用于加载dataId为example的配置源，autoRefreshed表示开启自动更新

＠NacosValue：设置属性的值，其中info表示key，而Local Hello World代表默认值。也就是说，如果key不存在，则使用默认值。这是一种高可用的策略，在实际应用中，我们需要尽可能考虑到在配置中心不可用的情况下如何保证服务的可用性

Nacos集成Spring Cloud 实现统一配置管理

添加Nacos Config的spring-cloud-starter依赖

创建bootstrap.properties文件，并在bootstrap.properties中添加Nacos Server的连接地址

在Nacos Console中创建如下配置

在启动类中，读取配置中心的数据

DataId配置加载规则

默认规则：${prefix}-${spring.profile.active}.${file-extension}

默认加载DataId=${spring.application.name}.${file-extension:properties}为前缀的基础配置

如果明确指定了spring.cloud.nacos.config.prefix=example属性，则会加载DataId=example的配置

spring.profile.active表示多环境支持

提供了YAML配置格式支持

在bootstrap.properties中声明 spring.cloud.nacos.config.file-extension=yaml

在Nacos控制台上增加配置：Data ID:spring-cloud-nacos-config-sample.yaml

要加载的配置文件

先加载 ${spring.application.name}.${file-extension:properties}的基础配置（多个环境共同配置）

再加载 ${spring.application.name}-${profile}.${file-extension:properties}的基础配置（每个环境独有配置）

通过-Dspring.profiles.active=${profile}启动可以动态控制要加载的环境配置

Namespace和Group使用说明

Nacos配置数据模型

Namespace

默认值：public

解决多环境及多租户数据的隔离问题

在不同的Namespace下，可以存在相同的Group或DataId

Group

默认值：DEFAULT_GROUP

用来实现DataId分组管理的机制

可以实现不同环境下的DataId的分组，也可以实现不同应用或者组件下使用相同配置类型的分组

专注在业务层面的数据分组

DataId

是Nacos中某个配置集的ID，它通常用于组织划分系统的配置集（应用配置）

自定义扩展DataId配置

示例

配置说明

spring.cloud.nacos.config.ext-config[n]支持多个Data ID的扩展配置，包含三个属性：data-id、group、refresh

spring.cloud.nacos.config.ext-config[n].data-id指定Nacos Config的Data ID

spring.cloud.nacos.config.ext-config[n].group指定Data ID所在的组

spring.cloud.nacos.config.ext-config[n].refresh控制Data ID在配置发生变更时是否动态刷新，以感知最新的配置值。默认是false，也就是不会实现动态刷新

注意点

spring.cloud.nacos.config.ext-config[n].data-id的值必须要带文件的扩展名，可以支持properties、yaml、json等

spring.cloud.nacos.config.ext-config[n].data-id配置多个Data ID时，n 的值越大，优先级越高

在ext-config和${spring.application.name}.${file-extension:properties}都存在的情况下，优先级高的是后者

优点

可以解决多个应用的配置共享问题

实现原理及源码解析

Nacos Config 实现原理解析

配置管理的4种操作

获取配置：从Nacos Config Server中读取配置

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

发布配置：将配置保存到Nacos Config Server中

删除配置：删除配置中心的指定配置

配置的CRUD

原理图

本质上就是调用Nacos Server的OpenAPI

配置的动态监听

Pull模式

表示客户端从服务端主动拉取数据

在Pull模式下，客户端需要定时从服务端拉取一次数据，由于定时任务会存在一定的时间间隔，所以不能保证数据的实时性。并且在服务端配置长时间不更新的情况下，客户端的定时任务会做一些无效的Pull

Push模式

表示服务端主动把数据推送到客户端

对于Push模式来说，服务端需要维持与客户端的长连接，如果客户端的数量比较多，那么服务端需要耗费大量的内存资源来保存每个连接，并且为了检测连接的有效性，还需要心跳机制来维持每个连接的状态

Nacos采用Pull模式

重点：不是简单的Pull，而是一种长轮询机制，它结合Push和Pull两者的优势

1. 客户端采用长轮询的方式定时发起Pull请求，去检查服务端配置信息是否发生了变更，如果发生了变更，则客户端会根据变更的数据获得最新的配置。所谓长轮询，是客户端发起轮询请求之后，服务端如果有配置发生变更，就直接返回

2. 如果客户端发起Pull请求后，发现服务端的配置和客户端的配置是保持一致的，那么服务端会先“Hold”住这个请求，也就是服务端拿到这个连接之后在指定的时间段内一直不返回结果，直到这段时间内配置发生变化，服务端会把原来“Hold”住的请求进行返回

3. Nacos服务端收到请求之后，先检查配置是否发生了变更，如果没有，则设置一个定时任务，延期29.5s执行，并且把当前的客户端长轮询连接加入allSubs队列

3.1 有两种方式触发该连接结果的返回

长轮询机制流程图

第一种是在等待29.5s后触发自动检查机制，这时候不管配置有没有发生变化，都会把结果返回客户端。而29.5s就是这个长连接保持的时间

第二种是在29.5s内任意一个时刻，通过Nacos Dashboard或者API的方式对配置进行了修改，这会触发一个事件机制，监听到该事件的任务会遍历allSubs队列，找到发生变更的配置项对应的ClientLongPolling任务，将变更的数据通过该任务中的连接进行返回，就完成了一次“推送”操作

3.2 Nacos长轮询机制的优点：既能够保证客户端实时感知配置的变化，也降低了服务端的压力。其中，这个长连接的会话超时时间默认是30s

Nacos在SpringCloud配置加载实现原理

Spring提供的统一环境配置抽象类Environment

整合了各种各样的外部环境

并且提供统一访问的方法 getProperty(String key)

在Spring启动时，会把配置加载到Environment中

当创建一个Bean时可以从Environment中把一些属性值通过＠Value的形式注入业务代码

SpringCloud实现配置的动态刷新，需解决的问题

如何将远程服务器上的配置加载到Environment

配置变更时，如何将新的配置更新到Environment中，保证配置变更时可以进行属性值的动态刷新

实现原理流程

ApplicationEnvironmentPreparedEvent事件类