微服务架构 | 2.2 Alibaba Nacos 的统一配置管理

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
简介: Nacos 致力于解决微服务中的统一配置、服务注册与发现等问题。它提供了一组简单易用的特性集,帮助开发者快速实现动态服务发现、服务配置、服务元数据及流量管理;

前言

参考资料
《Spring Microservices in Action》
《Spring Cloud Alibaba 微服务原理与实战》
《B站 尚硅谷 SpringCloud 框架开发教程 周阳》
《Nacos 官网》

Nacos 致力于解决微服务中的统一配置、服务注册与发现等问题。它提供了一组简单易用的特性集,帮助开发者快速实现动态服务发现、服务配置、服务元数据及流量管理;


1. Nacos 配置中心基础知识

1.1 Nacos 在配置中心中的功能

  • CRUD、版本管理、灰度管理、监听管理、推送轨迹、聚合数据等功能;

1.2 Nacos 配置管理 Data ID 的构成

  • ${prefix}-${spring.profiles.active}.${file-extension}
  • 默认为:${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}

    • prefix:默认为 spring.application.name 的值,也可以通过配置项 spring.cloud.nacos.config.prefix 来配置;
    • spring.profiles.active:即为当前环境对应的 profile。当 spring.profiles.active 为空时,对应的连接符 - 也将不存在,dataId 的拼接格式变成 ${prefix}.${file-extension}
    • file-exetension:为配置内容的数据格式,可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。目前只支持 properties 和 yaml 类型;

Nacos 配置管理 dataId 的构成

1.3 Nacos 配置的回滚机制

  • Nacos 会记录配置文件的历史版本默认保留 30 天,此外还有一键回滚功能,回滚操作将会触发配置更新;

Nacos 配置的回滚

1.4 Nacos 配置的图形化管理界面

  • 配置管理;

配置列表

  • 命名空间;

命名空间

1.5 Namespace、Group、Data ID 三者的关系

Namespace、Group、Data ID 三者的关系

  • 类似 Java 里面的 package 名和类名,最外层的 Namespace 是可以用于区分部署环境的,GroupData ID 逻辑上区分两个目标对象;
  • 默认情况下,Namespace=publicGroup=DEFAULT_GROUPCluster=DEFAULT

    • Namespace 命名空间:主要用来实现隔离,用于解决多环境及多租户数据的隔离问题。比如有三个环境:开发、测试、生产环境,可以创建三个Namespace,不同的Namespace 之间是隔离的;
    • Group 分组:可以把不同的微服务划分到同一个分组里面去,用来实现 Data ID 分组管理的机制;
    • Data ID:通常用于组织划分系统的配置集;
    • Cluster 簇:对指定微服务的一个虚拟划分;
    • Instance 实例:微服务的实例;
  • 官方的建议是,通过 Namespace 来区分不同的环境,而 Group 可以专注在业务层面的数据分组;

1.6 Nacos 对配置的 CRUD

  • 主要通过提供 Open API 接口或 SDK 实现;
  • 客户端通过 Open API 或调用 SDK 接口发送请求给服务器,服务器解析请求,并做相应的处理;

配置的 CRUD

对配置的操作 SDK Open API 说明
发布配置 public boolean publishConfig(String dataId, String group, String content) throws NacosException POST: /nacos/v1/cs/configs 将配置保存到 Nacos Config Server 中
删除配置 public boolean removeConfig(String dataId, String group)throws NacosException DELETE: /nacos/v1/cs/configs 删除配置中心的指定配置
获取配置 public string getConfig(String dataId, String group, long timeoutMs) throws NacosException GET: /nacos/v1/cs/configs 从 Nacos Config Server 中读取配置
监听配置 public void addListener(String dataId, String group, Listener listener) POST: /nacos/v1/cs/configs/listener 订阅感兴趣的配置,当配置发生变化时可以收到一个事件

1.7 Nacos 动态监听的长轮询机制

  • 一般来说,动态监听有两种机制:
比较项 Pull 机制 Push 机制
说明 客户端从服务端主动拉取数据 服务端主动把数据推送到客户端
缺点 不能保证数据实时性;在服务端配置长时间不更新的情况下,客户端的定时任务会做一些无效的 Pull 如果客户端的数量比较多,服务端需要耗费大量的内存资源来保存每个连接;需要心跳机制来维持每个连接状态
  • Nacos 的解决方案:长轮询机制

Nacos 动态监听的长轮询机制

  • 如果客户端发起 Pull 请求,服务端收到请求之后,先检查配置是否发生了变更:

    • 变更:返回变更配置;
    • 无变更:设置一个定时任务,延期 29.5s 执行,把当前的客户端长轮询连接加入 allSubs 队列;
  • 在这 29.5s 内的配置变化:

    • 配置无变化:等待 29.5s 后触发自动检查机制,返回配置;
    • 配置变化:在 29.5s 内任意一个时刻配置变化,会触发一个事件机制,监听到该事件的任务会遍历 allSubs 队列,找到发生变更的配置项对应的 ClientLongPolling 任务,将变更的数据通过该任务中的连接进行返回。相当于完成了一次 PUSH 操作;
  • 长轮询机制结合了 Pull 机制和 Push 机制的优点;
  • 源码分析详情请见:微服务架构 | *2.5 Nacos 长轮询定时机制的源码分析

1.8 Nacos 配置中心的源码分析


2. Nacos 基础配置

以 Data ID 方案为例,更多方案详情请见本篇第三点《3. Nacos 加载配置的三种方案》;

2.1 下载 Nacos 服务器

2.2 引入 pom.xml 依赖文件

<!--nacos-config-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

2.3 修改 yml 配置文件

  • bootstrap.yml
# nacos配置
server:
  port: 18082

spring:
  application:
    name: nacos-config-client     #必须,构成 Nacos 配置管理 Data ID 字段的一部分
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848     #Nacos 服务注册中心地址
      config:
        server-addr: localhost:8848     #Nacos 作为配置中心地址
        file-extension: yaml     #指定 yaml 格式的配置
        
        # prefix: hhh     #Data ID 的前缀,如果不指定,就是 nacos-config-client-dev.yaml。指定后,是 hhh-dev.yaml
        # refresh: true      #是否动态刷新
        
        # group: DEFAULT_GROUP     #指定组
        # namespace: PUBLIC     #指定命名空间 ID
  • application.yml
spring:
  profiles:
    active: dev # 表示开发环境

2.4 在主程序类上添加注解

  • @EnableDiscoveryClient:使用其他组件(Nacos、zookeeper、Consul)作为注册中心;

2.5 编写业务类

  • 这里仅编写一个 controller 作为示例:
@RestController
@RefreshScope //使当前类下的配置支持 Nacos 的动态刷新功能
public class ConfigClientController{
    @Value("${config.info}")
    private String configInfo;

    @GetMapping("/config/info")
    public String getConfigInfo() {
        return configInfo;
    }
}

2.6 在 Nacos 服务器中添加配置信息

  • 在 Nacos 服务器里新建并添加配置:

Nacos 新建配置
Nacos 新建配置2
Nacos 新建配置成功

  • 启动服务,调用接口:http://localhost:18082/config/info 获取配置信息;

启动服务,调用接口

2.7 报错无法装配 bean

  • 注意:如果 .yml 和 Nacos 服务器配置的 Data ID 匹配不上,将导致 ConfigClientController 类里的 ${config.info} 找不到,最终报 ConfigClientController 无法装配的错误,如下:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'scopedTarget.configClientController': Injection of autowired dependencies failed; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'config.info' in value "${config.info}"
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:380) ~[spring-beans-5.1.8.RELEASE.jar:5.1.8.RELEASE]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1411) ~[spring-beans-5.1.8.RELEASE.jar:5.1.8.RELEASE]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:592) ~[spring-beans-5.1.8.RELEASE.jar:5.1.8.RELEASE]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:515) ~[spring-beans-5.1.8.RELEASE.jar:5.1.8.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$1(AbstractBeanFactory.java:356) ~[spring-beans-5.1.8.RELEASE.jar:5.1.8.RELEASE]
    at org.springframework.cloud.context.scope.GenericScope$BeanLifecycleWrapper.getBean(GenericScope.java:389) ~[spring-cloud-context-2.1.2.RELEASE.jar:2.1.2.RELEASE]
    at org.springframework.cloud.context.scope.GenericScope.get(GenericScope.java:186) ~[spring-cloud-context-2.1.2.RELEASE.jar:2.1.2.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:353) ~[spring-beans-5.1.8.RELEASE.jar:5.1.8.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199) ~[spring-beans-5.1.8.RELEASE.jar:5.1.8.RELEASE]
    at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1105) ~[spring-context-5.1.8.RELEASE.jar:5.1.8.RELEASE]
    at org.springframework.cloud.context.scope.refresh.RefreshScope.eagerlyInitialize(RefreshScope.java:134) ~[spring-cloud-context-2.1.2.RELEASE.jar:2.1.2.RELEASE]
    at org.springframework.cloud.context.scope.refresh.RefreshScope.start(RefreshScope.java:125) ~[spring-cloud-context-2.1.2.RELEASE.jar:2.1.2.RELEASE]
    at org.springframework.cloud.context.scope.refresh.RefreshScope.onApplicationEvent(RefreshScope.java:119) ~[spring-cloud-context-2.1.2.RELEASE.jar:2.1.2.RELEASE]
    at org.springframework.cloud.context.scope.refresh.RefreshScope.onApplicationEvent(RefreshScope.java:73) ~[spring-cloud-context-2.1.2.RELEASE.jar:2.1.2.RELEASE]
    at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172) ~[spring-context-5.1.8.RELEASE.jar:5.1.8.RELEASE]
    ......


3. Nacos 加载配置的三种方案

  • 以下对 bootstrap.yml 的修改都可以在启动时配置 JVM 环境替代,使用如下命令:
  • -Dspring.profiles.active=${profile}

3.1 Data ID 方案

  • 新建三个 Data ID 的环境:

三个 Data ID 的环境

  • 指定 spring.profile.active 中的配置,重启服务,可以看到配置已经切换成其他环境了:
spring:
  profiles:
    active: prod

配置切换成其他环境

3.2 Group 方案

  • 新建三个 Group 的环境:

三个 Group 的环境

  • 指定 spring.profile.activespring.cloud.nacos.config.group 中的配置,重启服务,可以看到配置已经切换成其他环境了:
  • application.yml
spring:
  profiles:
    active: info #修改
  • bootstrap.yml
server:
  port: 18082
spring:
  application:
    name: nacos-config-client
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848 
      config:
        server-addr: localhost:8848
        file-extension: yaml
        group: PROD_GROUP #新增

配置切换成其他 Group 环境

3.3 Namespace 方案

  • 新建两个 Namespace 的环境:

新建两个命名空间
三个命名空间

  • 克隆 / 新建几份配置文件到新的命名空间,然后编辑修改;

克隆三份配置文件到其他命名空间

  • 指定 spring.profile.activespring.cloud.nacos.config.group 中的配置,重启服务,可以看到配置已经切换成其他环境了:
  • application.yml
spring:
  profiles:
    active: dev #修改
  • bootstrap.yml
server:
  port: 18082
spring:
  application:
    name: nacos-config-client
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848 
      config:
        server-addr: localhost:8848
        file-extension: yaml
        group: DEFAULT_GROUP #新增
        namespace: 48b2da7d-0b26-4c15-907b-9a379db8f7de #新增,命名空间的 ID,在新建命名空间时会给出

配置切换成其他命名空间环境


相关文章
|
25天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
6天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
24天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
6天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
102 68
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
24天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
40 1
服务架构的演进:从单体到微服务的探索之旅
|
22天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
45 8
|
23天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
43 5
|
24天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
32 5
|
24天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
25天前
|
监控 持续交付 Docker
Docker 容器化部署在微服务架构中的应用有哪些?
Docker 容器化部署在微服务架构中的应用有哪些?