首页  思维导图  详情

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

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





AI智能生成

为你推荐

查看更多



Spring Cloud 微服务技术栈

Spring Cloud Alibaba微服务架构

spring cloud 微服务

配置中心

Alibaba Nacos服务配置中心

spring cloud alibaba微服务技术架构

Spring Cloud Alibaba 微服务原理与实战

Spring Cloud Alibaba 微服务框架 Spring Cloud Gateway：微服务网关

Spring Cloud Alibaba 微服务架构

Spring Cloud Alibaba 使用手册

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

Nacos

作者其他创作

大纲/内容

服务地址的管理

服务注册

服务动态感知

注册中心

图片

Provider：服务提供者

Consumer：服务消费者

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

Open API

Config Service

Naming Service

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

Nacos Server：Nacos服务提供者

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配置实体模型

数据模型

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

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

API说明

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

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

临时实例

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

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

持久化实例

一些基础的组件例如数据库、缓存等，这些往往不能上报心跳，这种类型的服务在注册时，就需要作为持久化实例注册

上层的业务服务，例如微服务或者 Dubbo 服务，服务的 Provider 端支持添加汇报心跳的逻辑，此时就可以使用动态服务的注册方式

相关中间件对比

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

Nacos 注册配置中心介绍

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

参考资料

Nacos之注册中心

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

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

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

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

本地配置方式的不足

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

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

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

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

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

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

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

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

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

在Nacos Console中创建如下配置

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

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

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

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

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

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

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

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

提供了YAML配置格式支持

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

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

要加载的配置文件

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

DataId配置加载规则

Nacos配置数据模型

默认值：public

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

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

Namespace

默认值：DEFAULT_GROUP

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

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

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

Group

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

示例

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}都存在的情况下，优先级高的是后者

注意点

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

优点

自定义扩展DataId配置

DataId

Namespace和Group使用说明

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

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

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

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

配置管理的4种操作

原理图

本质上就是调用Nacos Server的OpenAPI

配置的CRUD

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

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

Pull模式

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

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

Push模式

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

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

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

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

长轮询机制流程图

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

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

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

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

Nacos采用Pull模式

配置的动态监听

Nacos Config 实现原理解析

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

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

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

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

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

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

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