1 前言
有专门的和来管理配置,但它也有一些局限性,所以还是希望通过来管理。在上面的微服务系统会有所不同,我们来探索一下如何整合来做配置管理。
整体方案与《使用Spring Cloud Config统一管理配置,别再到处放配置文件了》差不多,只是引入来使用的服务发现,而不使用等。
2 服务端
引入依赖:
服务端启动类如下:
服务端的配置如下:
这里的应用名字为,后续部署到也是用这个名字。
的资源定义文件如下:
保持名字统一为。
3 客户端
引入依赖:
为服务发现;
作为配置客户端;
提供EndPoint来刷新配置。
启动类为:
配置文件如下:
展示配置结果的服务:
客户端的文件:
注意名字为。
4 部署与测试
总结一下,服务端主要做了两件事:
(1)提供配置服务,从中读取配置;
(2)把自己注册到中去,以让客户端发现并读取配置。
客户端主要做了件事:
(1)作为配置客户端,从服务端读配置;
(2)把自己注册到中去,让服务端可以访问;
(3)提供刷新配置的功能给外界调用。
根据客户端的名字、配置的和,客户端便会读取分支的配置文件的内部。
访问结果如下:
如果修改了配置信息,客户端不能及时生效,需要通过发送请求到,这点不再赘述。
5 服务端统一刷新
如果改了大量配置,或者基础配置,想让所有客户端生效怎么办?总不能一个个去刷新?而且在客户端有多个需要的情况下,无法确保每个应用都能刷新到。
所以让服务去读取所有相关的客户端,并刷新。实现很简单,直接新增一个就可以了:
注意上面的过滤逻辑,因为不是所有都可以、都需要refresh,具体逻辑看业务。
请求结果如下(把客户端的设置成了):
注:可能会遇到权限不足的问题,创建一个对应的即可,不清楚可以参考:把Spring Cloud Data Flow部署在Kubernetes上,再跑个任务试试
“
客户端其实不一定需要引入,如果不通过的来寻找地址,而是直接配置服务端地址。但服务端是需要的,因为要获取客户端的信息来实现统一。
6 总结
配置管理其实是一门大学问,把放在上用只是其中一种场景。
领取专属 10元无门槛券
私享最新 技术干货