21天微服务培训第5天打卡作业中,需要大家在可执行jar包中放置一份microservice.yaml配置文件来覆盖jar包内的配置,然后用环境变量配置来覆盖配置文件的配置。部分同学会发现磁盘目录里的microservice.yaml文件、环境变量无法起到覆盖配置的效果,原因通常有以下几种:
1. microservice.yaml文件没有被加载
查看服务的cse.log日志文件,搜索关键字"create local config",查看其下的加载记录,可以看到类似这样的内容
|
1 2 3 4 5 |
|
表示总共加载了四份microservice.yaml配置文件,前三份是jar包内的,最后一份是磁盘文件。这里的microservice.yaml文件是越靠后的优先级越高。
如果没有看到加载磁盘文件,只加载了jar包内的microservice.yaml文件,则说明你的microservice.yaml文件没被加载。可能的原因有多种:
- microservice.yaml文件的文件名不对、存放目录不对
- 打包插件配置不对,jar包所在目录不在classpath中
前者需要你自行检查配置文件,后者可以通过将jar包当做zip包解压,查看META目录下的MANIFEST.MF文件来排查。如果的确没有将"."目录加入到classpath中,则需要检查你在pom文件中设置的打包插件是否有问题,建议和demo文件比对一下。
MANIFEST.MF文件示例:

2. microservice.yaml文件的字符集、换行符问题
推荐使用UTF-8字符集和Unix换行符以避免可能出现的问题。
3. 有旧provider服务的JVM进程残留,占用了端口
有些同学可能没有将旧的provider服务的实例关闭,导致旧provider服务的进程还在运行,占用着8080端口。此时新的provider服务启动时无法监听8080端口,即使它加载了配置文件,由于你发送的请求是由旧provider服务实例来处理的,你还是看不到响应消息有任何变化。
此时可以执行 jps -l 命令检查一下是否有遗留的provider服务实例进程。如果有进程残留建议先全部kill掉再重新启动provider服务。

在微服务培训中,遇到磁盘上的microservice.yaml文件和环境变量无法覆盖jar包内配置的问题。排查方法包括:检查microservice.yaml是否被加载,确认文件名、路径和classpath设置;确保文件使用UTF-8字符集和Unix换行符;检查是否存在旧服务JVM进程占用端口。通过日志、文件解析和进程管理解决配置加载问题。
8946

被折叠的 条评论
为什么被折叠?



