2.2.1 服务发现中心
根据上节讲解的网关的架构图,要使用网关首先搭建Nacos。
首先搭建Nacos服务发现中心。
在搭建Nacos服务发现中心之前需要搞清楚两个概念:namespace和group
namespace:用于区分环境、比如:开发环境、测试环境、生产环境。
group:用于区分项目,比如:xuecheng-plus项目、xuecheng2.0项目
首先在nacos配置namespace:
登录Centos,启动Naocs,使用sh /data/soft/restart.sh将自动启动Nacos。
访问:http://192.168.101.65:8848/nacos/
账号密码:nacos/nacos
登录成功,点击左侧菜单“命名空间”进入命名空间管理界面,
点击“新建命名空间”,填写命名空间的相关信息。如下图:
使用相同的方法再创建“测试环境”、"生产环境"的命名空间。
创建成功,如下图:
这里创建具体班级的命名空间,假如创建1010班级的命名空间,如下:
首先完成各服务注册到Naocs,下边将内容管理服务注册到nacos中。
1) 在xuecheng-plus-parent中添加依赖管理
2)在内容管理模块的接口工程、系统管理模块的接口工程中添加如下依赖
3)配置nacos的地址
在系统管理的接口工程的配置文件中配置如下信息:
在内容管理的接口工程的配置文件中配置如下信息:
4)重启内容管理服务、系统管理服务。
待微服务启动成功,进入Nacos服务查看服务列表
在 “开发环境” 命名空间下有两个服务实例。微服务在Nacos注册成功。
点击其它一个微服务的“详情”
通过上图可以查看微服务实例的地址。
2.2.2 配置中心
2.2.2.1 配置三要素
搭建完成Nacos服务发现中心,下边搭建Nacos为配置中心,其目的就是通过Nacos去管理项目的所有配置。
先将项目中的配置文件分分类:
1、每个项目特有的配置
是指该配置只在有些项目中需要配置,或者该配置在每个项目中配置的值不同。
比如:spring.application.name每个项目都需要配置但值不一样,以及有些项目需要连接数据而有些项目不需要,有些项目需要配置消息队列而有些项目不需要。
2、项目所公用的配置
是指在若干项目中配置内容相同的配置。比如:redis的配置,很多项目用的同一套redis服务所以配置也一样。
另外还需要知道nacos如何去定位一个具体的配置文件,即配置的三要素:namespace、group、dataid.
1、通过namespace、group找到具体的环境和具体的项目。
2、通过dataid找到具体的配置文件,dataid有三部分组成,
比如:content-service-dev.yaml配置文件 由(content-service)-(dev). (yaml)三部分组成
content-service:第一部分,它是在application.yaml中配置的应用名,即spring.application.name的值。
dev:第二部分,它是环境名,通过spring.profiles.active指定,
Yaml: 第三部分,它是配置文件 的后缀,目前nacos支持properties、yaml等格式类型,本项目选择yaml格式类型。
所以,如果我们要配置content-service工程的配置文件:
在开发环境中配置content-service-dev.yaml
在测试环境中配置content-service-test.yaml
在生产环境中配置content-service-prod.yaml
2.2.2.2 配置content-service
下边以开发环境为例对content-service工程的配置文件进行配置,进入nacos,进入开发环境。
点击 加号,添加一个配置
输入data id、group以及配置文件内容。
为什么没在nacos中配置下边的内容 ?
因为刚才说了dataid第一部分就是spring.application.name,nacos 客户端要根据此值确定配置文件 名称,所以spring.application.name不在nacos中配置,而是要在工程的本地进行配置。
本地配置文件现在是application.yaml需要修改为bootstrap.yaml,因为SpringBoot读取配置文件 的顺序如下:
所以在content-service工程 中添加bootstrap.yaml,内容如下:
最后删除原来的application.yaml。
在内容管理模块的接口工程和service工程、系统管理的接口工程和service工程配置依赖:
配置完成,运行content-service工程 的单元测试文件,能否正常测试。
通过运行观察控制台打印出下边的信息:
NacosRestTemplate.java通过Post方式去nacos读取配置信息。
跟踪单元测试方法可以正常读取数据库的数据,说明从nacos读取配置信息正常。
2.2.2.3配置content-api
以相同的方法配置content-api工程的配置文件,在nacos中的开发环境中配置content-api-dev.yaml,内容如下:
在content-api工程 的本地配置bootstrap.yaml,内容如下:
注意:因为api接口工程依赖了service工程 的jar,所以这里使用extension-configs扩展配置文件 的方式引用service工程所用到的配置文件。
如果添加多个扩展文件,继续在下添加即可,如下:
启动content-api工程,查询控制台是否打印出了请求nacos的日志,如下:
并使用Httpclient测试课程查询接口是否可以正常查询。
2.2.3 公用配置
还有一个优化的点是如何在nacos中配置项目的公用配置呢?
nacos提供了shared-configs可以引入公用配置。
在content-api中配置了swagger,所有的接口工程 都需要配置swagger,这里就可以将swagger的配置定义为一个公用配置,哪个项目用引入即可。
单独在xuecheng-plus-common分组下创建xuecheng-plus的公用配置,进入nacos的开发环境,添加swagger-dev.yaml公用配置
删除接口工程中对swagger的配置。
项目使用shared-configs可以引入公用配置。在接口工程的本地配置文件 中引入公用配置,如下:
再以相同 的方法配置日志的公用配置。
在接口工程和业务工程,引入loggin-dev.yaml公用配置文件
配置完成,重启content-api接口工程,访问http://localhost:63040/content/swagger-ui.html 查看swagger接口文档是否可以正常访问,查看控制台log4j2日志输出是否正常。
2.2.4 系统管理配置
按照上边的方法 自行将系统管理服务的配置信息在nacos上进行配置。
2.2.5 配置优先级
到目前为止已将所有微服务的配置统一在nacos进行配置,用到的配置文件有本地的配置文件 bootstrap.yaml和nacos上的配置文件,引入配置文件的形式有:
1、通过dataid方式引入
2、以扩展配置文件方式引入
3、以共享配置文件 方式引入
下边测试这几种配置文件方式的优先级。
我们使用内容管理服务中的配置文件,首先在共享配置文件 swagger-dev.yaml中配置四个配置项,如下:
配置完成发布。
下边在content-api工程的启动类中添加如下代码读取这四个配置项的值
启动content-api工程,在return new Integer(1);处打断点,运行到断点处,如下:
这说明已经成功读取到 四个配置项的值。
下边在content-api工程的扩展配置文件 conent-service-dev.yaml中配置三个配置项,如下:
再次重启content-api工程,在return new Integer(1);处打断点,运行到断点处,如下:
从结果可以看出,扩展配置文件比共享配置文件优先级高。
下边继续content-api-dev.yaml中配置两个配置项,如下:
再次重启内容管理接口工程,在return new Integer(1);处打断点,运行到断点处,如下:
从结果可以看出,通过工程的应用名找到配置文件 content-api-dev.yaml优先级比扩展配置文件 高。
下边我们在content-api工程的本地配置文件bootstrap.yaml中配置如下:
再次重启内容管理接口工程,在return new Integer(1);处打断点,运行到断点处,如下:
这说明本地配置文件配置的内容没有起作用,原因是nacos配置文件中的相同的配置项覆盖了本地的配置项。
到这可以总结各各配置文件 的优先级:项目应用名配置文件 > 扩展配置文件 > 共享配置文件 > 本地配置文件。
有时候我们在测试程序时直接在本地加一个配置进行测试,这时我们想让本地最优先,可以在nacos配置文件 中配置如下即可实现:
再次重启content-api工程,在return new Integer(1);处打断点,运行到断点处,如下:
可以看出此时本地配置最优先。
2.2.6 导入配置文件
课程资料中提供了系统用的所有配置文件nacos_config_export.zip,下边将nacos_config_export.zip导入nacos。
进入具体的命名空间,点击“导入配置”
打开导入窗口
相同的配置选择覆盖配置。
点击“上传文件”选择nacos_config_export.zip开始导入。