1.nacos定义:一个更易于构建云原生应用的动态服务发现、服务配置和服务管理平台。
(注册中心+配置中心+服务管理)
2.nacos的关键特性包括:
服务发现和服务健康检测:Nacos使用服务更容易注册,通过DNS/HTTP接口发现其他服务,Nacos还提供服务的实时健康检查,以防止向不健康的主机或服务实例发送请求。
动态配置服务:动态配置服务运行在所有环境中以集中和动态的方式管理所有的服务配置,Nacos消除了在更新配置时重新部署应用程序,使配置的更改更加高效和灵活。
动态DNS服务:Nacos提供基于DNS协议的服务发现能力,支持异构语言的服务发现,支持将注册在Nacos上的服务以域名的方式暴露端点,让三方应用方便的查阅和发现。
服务及其元数据管理。
管理所有微服务、解决微服务之间调用关系错综复杂、难以维护的问题。
1.Nacos discovery
服务注册发现:Nacos discovert starter
服务发现是微服务架构中最关键的组件之一。可以将服务自动注册到Nacos服务端并能够动态感知和刷新某个服务实例的服务列表,Nacos Discovery Starter也将服务实例自身的一些元数据信息,比如,host,port,健康检查URL,主页等注册到Nacos。
2.核心功能
1.服务注册:当服务一启动的时候,就会自动的将服务中的元数据注册到 Nacos服务注册中心的服务表中。
2.服务心跳:在微服务(Nacos客户端)有一个定时心跳来持续通知注册中心,说明服务一直处于可用状态,防止被删除,默认5s发送一次心跳。
3.服务同步:Nacos Server(Nacos 注册中心)集群的时候,集群之间会相互同步服务实例,用来保证服务信息的一致性。
4.服务发现:Nacos客户端在调用服务的时候,会发送一个rest请求给Nacos注册中心,获取注册的服务清单,并且将其缓存在Nacos客户端本地,在Nacos客户端本地开启一个定时任务定时拉取服务器最新的注册表信息更新到本地缓存。
5.服务健康检查:Nacos 注册中心会开启一个定时任务来检查注册服务实例的健康情况,对于超过15s没有收到客户端心跳的实例会将healthy属性设置为false,如果某个实例超过30s没有收到心跳,直接删除该实例(被删除的实例如果恢复心跳会重新注册)。
下载安装包并且修改相关的配置。
1.在config文件下,application.properties当中连接数据库
2.在bin目录下startup.cmd当中将集群启动改为单机启动。
将cluster改为standalone
1.配置集:在系统当中,一个配置文件通常是一个配置集,一个配置集包含了系统的各种配置信息。配置集的ID是Data ID。
2.配置分组:配置分组是对配置集进行分组,不同的配置分组下可以有相同的配置集,在Nacos上创建一个配置时,如果没有填写配置分组的名称,则配置分组的名称默认采用DEFAULT_GROUP。
3.命名空间:可以用于进行不同环境的配置隔离。
1.在bin目录下,启动nacos
2.http://192.168.237.1:8848/nacos/index.html是nacos的访问地址
3.登录的用户名和密码 默认都是nacos
4.新建一个配置
5.写一个简单的例子
>6.若application.yml 和bootstrap.yml 在同一目录下:bootstrap.yml 先加载 application.yml后加载.>创建bootstrap.yaml配置文件
7.创建一个类,主要用于测试:读取nacos配置文件中的内容,为了检测与nacos是否连接成功
8.结果展示:读取内容成功
2.访问路径:127.0.0.1:8089/configs
利用@Value()注解的方式获取到Nacos配置内容,不支持配置的动态更新,当配置内容发生改变,更新访问页面,获取到的内容并没有发生改变,针对这种情况,引入了 支持配置的动态更新。
上面这个是支持动态配置更新的,当Nacos配置内容发生改变,刷新127.0.0.1:8089/configs之后,得到的数据也会发生改变。
多个微服务会针对一个数据库进行操作,现在很多微服务采用的是分布式,如果在每一个微服务上都创建一个数据库的连接,当数据库需要更改的时候,此时的维护量就比较大,所以,利用Nacos来管理数据库的连接,多个微服务只需要在配置文件中引入Nacos的配置。
1.首先,新建一个命名空间 (dev)
2.在命名空间dev之下,新建配置
3.新建配置中添加相应的数据库连接
4.在bootstrap.yaml当中去引入这个nacosDemo
一般 一个微服务 对应一个nacos配置
但是,一个微服务也可以对应多个nacos配置,多个微服务也有一些公用的数据,可以放在同一个nacos配置。
1.自定义扩展DataId
1.在Nacos当中创建三个配置
2.在bootstrap.yaml当中添加这三个配置文件的data id 和group,其中设置了ext-config-demo3.properties为动态更新
3.在TestBootStrap.java当中测试一下,扩展 data id是否正确?是否可以拿到配置文件中的内容?
4.测试结果
5.总结:
需要使用Nacos中多个配置文件的时候,就需要在bootstrap当中配多个data id,此时就用到了:txt-config[i],在这个下面再写data-id和group。
在上面的ext-config[2]当中,多加了一个动态更新:refresh.
动态更新的作用主要体现在:当修改nacos配置文件中的信息的时候,更新127.0.01:8089/configs,获得的数据也会发生相应的改变。
2.自定义共享Data ID设置
1.还是使用上面创建好的Nacos配置文件
其中第一个group是默认的default_group,其余两个是自己写的
>2.设置自定义共享Data ID,在config下面设置:shared-dataids,refreshable-dataids
3.测试结果:
4.分析结果:
由上面结果可以看出来,使用共享data id的时候,只支持group为default_group,并不支持其他的,其他的读到都为null。
比较推荐使用自定义扩展data id
Spring Cloud Alibaba Nacos Config 提供了三种配置能力从Nacos中拉取相关的配置。
A.通过spring.cloud.nacos.config.shared-dataids支持多个共享Data Id的配置;
B.通过spring.cloud.nacos.config.ext-config[n].data-id的方式支持多个扩展Data Id的配置,多个Data Id同时配置的时候,优先级关系:其中的n越大,优先级越高。
C.通过内部相关规则:(应用名spring.application.name、扩展名spring.cloud.nacos.config.file-extension)自动生成相关的Data Id配置。
三种方式共同使用的时候,优先级是C>B>A。
当使用单机模式的nacos的时候,如果一个进程挂了,则nacos服务就不能用了,在实际的使用过程中,一般会使用集群部署的nacos。
1.什么是服务发现
在微服务架构中,整个系统会按照职责能力划分为多个服务,通过服务之间协作来实现业务目标。在代码中需要进行服务间的远程调用(生产方和消费方),服务的消费方要调用服务的生产方,为了完成一次请求,消费方需要直到服务生产方的网络位置(IP地址和端口号)。
2.微服务和微服务之间的调用
微服务可能部署在云环境的,服务实例的网路位置或许是动态分配的,每一个服务一般会有多个实例来做负载均衡,由于宕机或升级,服务实例网络地址会经常动态改变,每一个服务也可能应对临时访问压力增加新的服务点。
3.服务之间如何相互感知?服务如何管理?
这个就是服务发现的问题。
所有的服务实例内部都会包含 服务发现客户端。
1.每个服务启动时会向服务发现中心上报自己的网络位置。服务发现中心内部会形成一个服务注册表,服务注册表时服务发现的核心部分,包含所有的服务实例的网络地址的数据库。
2.服务发现客户端会定期从服务发现中心同步服务注册表,并缓存在客户端。
3.当需要对某服务进行请求时,服务实例通过该注册表,定位目标服务网络地址,如果目标服务存在多个网络地址,则使用负载均衡算法从多个服务实例中选择一个,发出请求。
在微服务环境中,服务运行实例的网络地址是不断动态变化的,服务实例数的动态变化,因此,无法使用固定的配置文件记录服务提供方的网络地址,必须使用动态的服务发现机制,用于微服务间的相互感知,各服务实例会上报自己的网络地址,这样服务中心就形成了一个完整的服务注册表,各个服务实例会通过服务发现中心来获取访问目标服务的网络地址,从而实现服务发现的机制。
Spring Cloud常见的集成方式是:Feign+Ribbon技术来完成服务间远程调用和负载均衡。
由Feign完成远程调用的流程,Feign集成了Ribbon,Feign使用Ribbon完成调用实例的负载均衡。
1.负载均衡的概念
负载均衡是将用户请求(流量)通过一定的策略,分摊在多个服务实例上执行,是系统处理高并发、缓解网络压力和进行服务端扩容的重要手段之一,分为服务端负载均衡和客户端负载均衡。
2.服务端的负载均衡
在负载均衡器中维护一个可用的服务实例清单,当客户端请求来临是时,负载均衡服务器按照某种配置好的规则(负载均衡算法)从可用的服务实例清单中选取一个去处理客户端的请求。
3.客户端服务负载均衡
Ribbon属于客户端负载均衡,在ribbon客户端会有一个服务实例地址列表,在发送请求之前通过负载均衡算法选择一个服务实例,进行访问,在客户端进行负载均衡算法分配。
4.Ribbon是一个客户端负载均衡器,责任是从一组实例列表中挑选合适的实例。–取决于 负载均衡策略。
Ribbon核心组件IRule时负载均衡策略接口,
1.RoundRobinRule轮询,按一定顺序轮换获取实例地址。
2.RandomRule随机,以随机的方式获取实例的地址。
3.AvailabilityFilteringRule:会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,以及并发的连接数量超过阈值的服务,对剩余的服务列表按照轮询策略进行访问。
4.WeightedResponseTimeRule:根据平均响应时间计算所有服务的权重,响应时间越快,服务权重越大,被选中的机率越高。
刚启动的时候,如果统计信息不足,使用RoundRobinRule策略,等统计信息足够,会切换到WeightedResponseTimeRule
5.RetryRule:先按照RoungRobinRule的策略获取服务,如果获取服务失败,在指定时间内会进行重试,获取可用的服务。
6.BestAvailableRule:会先过滤掉由于多次访问故障而处于段路器跳闸状态的服务,然后选择一个并发量最小的服务。
Feign时Netfilx开发的声明式、模板化的HTTP客户端,Feign可以更快捷、更优雅的调用HTTP API.
1.服务发现数据模型
Nacos是一种服务-集群-实例的三层模型,这样基本可以满足服务在所有场景下的数据存储和管理。
2.命名空间
命名空间不仅适用于nacos的配置管理,也适用于服务发现,namespace常用场景之一是不同环境的配置的区分隔离,比如开发测试环境和生产环境的资源隔离等。
3.服务名
服务提供的标识,通过该标识可以唯一确定其指代的服务。
4.实例
提供一个或多个服务的具有可访问网络地址的进程,启动一个进程,就产生一个服务实例。
5.元信息
Nacos数据描述信息,如,服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签、从作用范围来看,分为服务级别的元信息和实例的元信息。
6.集群
服务实例的集合,服务实例组成一个默认的集群,集群可以被进一步按需求划分,划分单位可以是虚拟集群,相同集群下的实例才可以互相感知。