将一个服务的多个实例部署到多个机房,把鸡蛋分散开,容灾。
一级是服务,往下是集群,再往下就是实例。
为什么要引入地域集群的划分呢?
为了防止出现跨集群的调用。
等启动好之后,在修改集群名字,启动其他服务。
查看控制台
要实现order-service进行user-service调用时,优先使用本地集群。这就需要给order-service设置集群属性。
配置集群名称
配置服务调用的规则(先访问本地集群的服务,在本地集群中又随机选择,本地挂掉在选择其他集群的服务)
优先选择本地集群,在本地集群的多个服务随机选择进行负载均衡。
实际部署中会出现这样的场景:
Nacos提供了权重配置来控制访问频率,权重越大则访问频率越高
当权重设置为0时,该服务根本就不会被访问。当服务升级的时候,我们不能将服务重启,因为用户还在访问。
我们可以将要升级的服务器权重设置为0,当该服务器没有请求了再做相关操作升级好了之后,将权重设置为小一点,先看看有没有问题。
环境服务实际上就是在对服务做隔离。
服务划分、实例划分是基于业务或者地域做的划分。但还有开发环境、测试环境的变化,所以有了环境隔离。
group分组:将业务相关度比较高的放到一组里面。例如订单和支付。
要想让服务访问要放在一个环境下。
1、服务的消费者并不是每次服务都要去nacos中拉取相关的服务列表,它会做一个缓存,并且进行定期的(30s)拉取更新缓存。
但是如果30s内服务提供者挂了,消费者怎么知道?
使用eurka是不能及时知道的,但是使用nacos是可以知道的,因为eurka只有一个拉取pull,所以时效性比较差,nacos是pull+push,如果nacos发现服务挂了,它会赶紧告诉服务消费者让它赶紧更新。
2、临时实例需要想nacos每隔30s发送心跳检测,如果临时实例挂了,那nacos就会把它从服务列表中删去。但是对于非临时实例(如同亲儿子),nacos会主动检测询问他是否还健康,当非临时实例挂了之后,nacos不会把他删除,而是将其标记为不健康,等它健康了再修改状态。
数十个服务的配置需要修改,我不需要逐一的去修改,而是在一个地方进行修改。并且希望在改动完之后,这个服务不用去做重启配置就能生效,就叫配置更改热更新。
nacos配置书写
并不是将application里面的配置全部挪过来,而是将有热更新需求的挪过来,填写核心的,将来会有变化的(开关类型的,固定模板的例如日期格式)。
配置获取
我们的项目要先去nacos中读取配置文件,但是去哪读取?读取谁?我们nacos的地址再application.yml文件中呢,所以我们要先知道nacos的地址,使用bootstrap.yml,将nacos的地址以及配置文件的相关信息都放在这个里面。
步骤:
三要素:服务名、环境、后缀名。决定了dataID
再去干掉application.yml文件中与bootatrap.yml文件中相同的配置。
将服务名称、nacos地址都干掉,集群地址注释掉
读取配置@Value(${}),来证明能拉取到bootstrap.yml的相关配置。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1rDxtYTs-1648003284536)(C:/Users/大 大/AppData/Roaming/Typora/typora-user-images/image-20220314164929057.png)]
另外一种属性注入方式:将其注入到对象里面去,再获取属性。
@ConfigurationProperties完成配置的自动加载。只要两者进行拼接和配置文件一致,就能完成属性的自动注入。
有一个配置在开发、测试、上线之后的属性值是一样的,对于这种不用每个环境都配置一次,而是使用多环境配置共享。
进行测试
在属性配置类里面添加对应的属性,再在controller里面书写相关方法可以进行请求调用。
修改环境
当本地配置和远端配置有相同的属性时,
多重配置的优先级
mg-Fiy3G5W4-1648003284552)]
[外链图片转存中…(img-38pYIXwf-1648003284553)]
[外链图片转存中…(img-X5EmBscs-1648003284554)]
多重配置的优先级
[外链图片转存中…(img-iM0e9lpA-1648003284555)]
[外链图片转存中…(img-mjzjAWHk-1648003284556)]