nacos学习笔记

是派大大欣

已于 2023-05-22 16:00:55 修改

阅读量185

点赞数

分类专栏： Java 文章标签：笔记微服务 java dubbo

于 2023-05-22 13:45:22 首次发布

本文链接：https://blog.csdn.net/Cynthia018/article/details/130801019

版权

Java 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

介绍

nacos主要应用于微服务架构的配置中心的构建。配置中间就是将配置文件统一的进行管理

配置中心

什么是配置

应用程序在启动和运行的时候，往往需要读取一些配置信息，配置基本上伴随着应用程序整个生命周期。例如，数据库连接参数，启动参数等。

配置是独立于程序的只读变量：配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置
配置伴随应用的整个生命周期：配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。比如：启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。
配置可以有多种加载方式：常见的有程序内部hard code，配置文件，环境变量，启动参数，基于数据库等。
配置需要治理：同一份程序在不同的环境（开发，测试，生产）、不同的集群（如不同的数据中心）经常需要有不同的配置，所以需要有完善的环境、集群配置管理。

什么是配置中心？

在微服务架构中，当系统从一个单体应用，被拆分成分布式系统上一个个服务节点后，配置文件也必须跟着迁移（分割），这样配置就分散了，不仅如此，分散中还包含着冗余。
在这里插入图片描述
配置中心将配置从各应用中剥离出来，对配置进行统一管理，应用自身不需要自己去管理配置。

总结一下，在传统巨型单体应用纷纷转向细粒度微服务架构的历史进程中，配置中心是微服务化不可缺少的一个系
统组件，在这种背景下中心化的配置服务即配置中心应运而生，一个合格的配置中心需要满足如下特性：

配置项容易读取和修改
分布式环境下应用配置的可管理性，即提供远程管理配置的能力
支持对配置的修改的检视以把控风险
可以查看配置修改的历史记录
不同部署环境下应用配置的隔离性

主流配置中心对比

在这里插入图片描述
从配置中心角度来看，性能方面Nacos的读写性能最高，Apollo次之，Spring Cloud Config依赖Git场景不适合开
放的大规模自动化运维API。功能方面Apollo最为完善，nacos具有Apollo大部分配置管理功能，而Spring Cloud
Config不带运维管理界面，需要自行开发。Nacos的一大优势是整合了注册中心、配置中心功能，部署和操作相比
Apollo都要直观简单，因此它简化了架构复杂度，并减轻运维及部署工作。

nacos

nacos简介

nacos是阿里的一个开源产品，它是针对微服务架构中的服务发现、配置管理、服务治理的综合型解决方案。

nacos特性

Nacos主要提供以下四大功能：

服务发现与服务健康检查
Nacos使服务更容易注册，并通过DNS或HTTP接口发现其他服务，Nacos还提供服务的实时健康检查，以防
止向不健康的主机或服务实例发送请求。
动态配置管理
动态配置服务允许您在所有环境中以集中和动态的方式管理所有服务的配置。Nacos消除了在更新配置时重新
部署应用程序，这使配置的更改更加高效和灵活。
动态DNS服务
Nacos提供基于DNS 协议的服务发现能力，旨在支持异构语言的服务发现，支持将注册在Nacos上的服务以
域名的方式暴露端点，让三方应用方便的查阅及发现。
服务和元数据管理
Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周
期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略。

这里动态配置管理的特性说明了Naocs的配置管理能力。

nacos配置管理

配置管理模型

对于Nacos配置管理，通过Namespace、Group、Data ID能够定位到一个配置集。
Namespace：可用于进行不同环境的配置隔离；
Group：配置分组是对配置集进行分组，可用于区分不同的项目或应用；
Data ID：每个项目下往往有若干个工程，每个配置集(DataId)是一个工程的主配置文件。
在这里插入图片描述

获取配置集需要指定

1、nacos服务地址，必须指定
2、namespace，如不指定默认public
3、group，如不指定默认 DEFAULT_GROUP
4、dataId，必须指定

namespace

在这里插入图片描述

监听查询

Nacos提供配置订阅者即监听者查询能力，同时提供客户端当前配置的MD5校验值，以便帮助用户更好的检查配
置变更是否推送到 Client 端。

public class SimpleDemoMainListener {
	public static void main(String[] args) throws NacosException {
		//nacos 地址
		String serverAddr = "127.0.0.1:8848";
		//Data Id
		String dataId = "nacos‐simple‐demo.yaml";
		//Group
		String group = "DEFAULT_GROUP";
		Properties properties = new Properties();
		properties.put("serverAddr",serverAddr);
		ConfigService configService = NacosFactory.createConfigService(properties);
		//获取配置,String dataId, String group, long timeoutMs
		String content = configService.getConfig(dataId, group, 5000);
		System.out.println(content);
		//添加监听String dataId, String group, Listener listener
		configService.addListener(dataId, group, new Listener() {
			public Executor getExecutor() {
				return null;
			} 
			public void receiveConfigInfo(String s) {
				//当配置发生变化时的响应
				System.out.println(s);
			}
		});
		// 测试让主线程不退出，因为订阅配置是守护线程，主线程退出守护线程就会退出。 正式代码中无需下面代码
		while (true) {
			try {
				Thread.sleep(1000);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		}
	}
}

Nacos配置管理应用于分布式系统

从单体架构到微服务架构

单体架构

在这里插入图片描述

复杂性逐渐变高，可维护性逐渐变差 ：所有业务模块部署在一起，复杂度越来越高，修改时牵一发动全身。
版本迭代速度逐渐变慢：修改一个地方就要将整个应用全部编译、部署、启动时间过长、回归测试周期过长。
阻碍技术创新：若更新技术框架，除非你愿意将系统全部重写，无法实现部分技术更新。
无法按需伸缩：通过冗余部署完整应用的方式来实现水平扩展，无法针对某业务按需伸缩。

微服务

在这里插入图片描述
微服务架构的好处：

分而治之，职责单一：易于开发、理解和维护、方便团队的拆分和管理
可伸缩：能够单独的对指定的服务进行伸缩
局部容易修改，容易替换，容易部署，有利于持续集成和快速迭代
不会受限于任何技术栈

分布式应用配置管理

在这里插入图片描述
用户通过Nacos Server的控制台集中对多个服务的配置进行管理。
各服务统一从Nacos Server中获取各自的配置，并监听配置的变化。

流程

发布配置
创建父工程
微服务service1配置：新建项目service1，bootstrap.yml配置，启动配置客户端
微服务service2配置：新建项目service2，bootstrap.yml配置，启动配置客户端
支持配置的动态更新

Nacos集群部署

3个或3个以上Nacos节点才能构成集群。

集群部署流程：

安装3个以上Nacos
配置集群配置文件在所有nacos目录的conf目录下，有文件 cluster.conf.example ，将其命名为 cluster.conf ，并将每行配置成 ip:port。（请配置3个或3个以上节点）
集群模式启动 startup ‐m cluster

客户端配置：所有客户端，分别指定nacos集群中的若干节点

nacos服务发现

在微服务架构中，整个系统会按职责能力划分为多个服务，通过服务之间协作来实现业务目标。服务之间要进行远程调用，服务的消费方要调用服务的生产方，为了完成一次请求，消费方需要知道服务生产方的网络位置(IP地址和端口号)。因此需要服务发现中心。

微服务可能是部署在云环境的，服务实例的网络位置或许是动态分配的。另外，每一个服务一般会有多个实例来做负载均衡，由于宕机或升级，服务实例网络地址会经常动态改变。再者，每一个服务也可能应对临时访问压力增加新的服务节点。
在这里插入图片描述

在这里插入图片描述

在每个服务启动时会向服务发现中心上报自己的网络位置。这样，在服务发现中心内部会形成一个服务注册表，服务注册表是服务发现的核心部分，是包含所有服务实例的网络地址的数据库。
服务发现客户端会定期从服务发现中心同步服务注册表，并缓存在客户端。
当需要对某服务进行请求时，服务实例通过该注册表，定位目标服务网络地址。若目标服务存在多个网络地址，则使用负载均衡算法从多个服务实例中选择出一个，然后发出请求。
总结一下，在微服务环境中，由于服务运行实例的网络地址是不断动态变化的，服务实例数量的动态变化，因此无法使用固定的配置文件来记录服务提供方的网络地址，必须使用动态的服务发现机制用于实现微服务间的相互感知。各服务实例会上报自己的网络地址，这样服务中心就形成了一个完整的服务注册表，各服务实例会通过服务发现中心来获取访问目标服务的网络地址，从而实现服务发现的机制。

Spring Cloud服务协作流程

Spring Cloud 常见的集成方式是使用Feign+Ribbon技术来完成服务间远程调用及负载均衡。
在这里插入图片描述

在微服务启动时，会向服务发现中心上报自身实例信息，这里ServiceB 包含多个实例。
每个实例包括：IP地址、端口号信息。
微服务会定期从Nacos Server(服务发现中心)获取服务实例列表。
当ServiceA调用ServiceB时，ribbon组件从本地服务实例列表中查找ServiceB的实例，如获取了多个实例如
Instance1、Instance2。这时ribbon会通过用户所配置的负载均衡策略从中选择一个实例。
最终，Feign组件会通过ribbon选取的实例发送http请求。
采用Feign+Ribbon的整合方式，是由Feign完成远程调用的整个流程。而Feign集成了Ribbon，Feign使用Ribbon
完成调用实例的负载均衡。

负载均衡

创建父工程
服务生产者：pom.xml的配置，application.yml配置，Provider(生产者)服务实现（注解RestController暴露服务），启动Provider(生产者) （注解EnableFeignClients）
服务消费者：pom.xml的配置，application.yml配置，Provider(生产者)远程代理定义（注解FeignClient），Consumer(消费者)服务实现（注解EnableFeignClients），多实例负载均衡

Spring Cloud Alibaba 综合集成架构演示

Spring Cloud是一个较为全面的微服务框架集，集成了如服务注册发现、配置中心、消息总线、负载均衡、断路器、API网关等功能实现。
Dubbo只是服务治理与RPC实现方案。
在这里插入图片描述

工程结构说明

nacos‐micro‐service 整体父工程
├─api‐gateway API网关，端口：56010
├─application‐1 应用1，端口：56020
├─service‐1 服务1父工程
│	├─service‐1‐api 服务1API
│	└─service‐1‐server 服务1实现，端口：56030
└─service‐2 服务2父工程
	├─service‐2‐api 服务2API
	└─service‐2‐server 服务2实现，端口：56040

流程

创建父工程
实现application1
a. 初始化 application-1 Maven 工程
b. 实现 application-1 功能
c. application1 配置
d. application1 启动
实现 Service1
a. 定义父工程
b. 定义service-1-api：定义服务接口
c. 实现service-1-server：初始化 service-1-server Maven 工程，实现 Dubbo 服务（注解@org.apache.dubbo.config.annotation.Service），配置 Dubbo 服务，启动服务消费方应用（注解EnableDiscoveryClient）
实现 application1调用Service1
引用service1：实现远程调用（注解@org.apache.dubbo.config.annotation.Reference）
实现 Service2同上
实现 application1调用Service2同上
实现service1调用service2（注解@org.apache.dubbo.config.annotation.Reference）

dubbo开头的为dubbo服务的配置：
dubbo.scan.base-packages : 指定 Dubbo 服务实现类的扫描基准包，将@org.apache.dubbo.config.annotation.Service注解标注的service暴露为dubbo服务。
dubbo.protocol : Dubbo 服务暴露的协议配置，其中子属性 name 为协议名称， port 为dubbo协议端口可以指定多协议，如：dubbo.protocol.rmi.port=1099
dubbo.registry : Dubbo 服务注册中心配置，其中子属性 address 的值 “nacos://127.0.0.1:8848”，说明dubbo服务注册到nacos相当于原生dubbo的xml配置中的 <dubbo:registry address=“10.20.153.10:9090” />

rpc、dubbo和http的区别

实现api-gateway

是派大大欣

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
nacos学习笔记

nacos主要应用于微服务架构的配置中心的构建。配置中间就是将配置文件统一的进行管理应用程序在启动和运行的时候，往往需要读取一些配置信息，配置基本上伴随着应用程序整个生命周期。例如，数据库连接参数，启动参数等。配置是独立于程序的只读变量：配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置配置伴随应用的整个生命周期：配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。
复制链接

扫一扫