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

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 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,在新建命名空间时会给出

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


相关文章
|
18天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
27天前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
42 3
|
17天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
131 68
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
16天前
|
运维 监控 持续交付
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
143 36
微服务架构解析:跨越传统架构的技术革命
|
15天前
|
Java Nacos Sentinel
Spring Cloud Alibaba:一站式微服务解决方案
Spring Cloud Alibaba(简称SCA) 是一个基于 Spring Cloud 构建的开源微服务框架,专为解决分布式系统中的服务治理、配置管理、服务发现、消息总线等问题而设计。
153 13
Spring Cloud Alibaba:一站式微服务解决方案
|
19天前
|
设计模式 负载均衡 监控
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
48 8
|
24天前
|
消息中间件 运维 Kubernetes
后端架构演进:从单体到微服务####
本文将探讨后端架构的演变过程,重点分析从传统的单体架构向现代微服务架构的转变。通过实际案例和理论解析,揭示这一转变背后的技术驱动力、挑战及最佳实践。文章还将讨论在采用微服务架构时需考虑的关键因素,包括服务划分、通信机制、数据管理以及部署策略,旨在为读者提供一个全面的架构转型视角。 ####
34 1
|
26天前
|
弹性计算 运维 开发者
后端架构优化:微服务与容器化的协同进化
在现代软件开发中,后端架构的优化是提高系统性能和可维护性的关键。本文探讨了微服务架构与容器化技术如何相辅相成,共同推动后端系统的高效运行。通过分析两者的优势和挑战,我们提出了一系列最佳实践策略,旨在帮助开发者构建更加灵活、可扩展的后端服务。
|
26天前
|
消息中间件 运维 Cloud Native
云原生架构下的微服务优化策略####
本文深入探讨了云原生环境下微服务架构的优化路径,针对服务拆分、通信效率、资源管理及自动化运维等核心环节提出了具体的优化策略。通过案例分析与最佳实践分享,旨在为开发者提供一套系统性的解决方案,以应对日益复杂的业务需求和快速变化的技术挑战,助力企业在云端实现更高效、更稳定的服务部署与运营。 ####
|
17天前
|
Cloud Native API 持续交付
云原生架构下的微服务治理策略与实践####
本文旨在探讨云原生环境下微服务架构的治理策略,通过分析当前面临的挑战,提出一系列实用的解决方案。我们将深入讨论如何利用容器化、服务网格(Service Mesh)等先进技术手段,提升微服务系统的可管理性、可扩展性和容错能力。此外,还将分享一些来自一线项目的经验教训,帮助读者更好地理解和应用这些理论到实际工作中去。 ####
34 0