微服务配置文件可视化集中管理 - 第一章
1.首先模拟配置中心,提供api接口供应用站点拉取配置信息.
2.应用站点继承ConfigurationProvider类,重写Load()函数,实现从远程配置中心提供的api接口拉取配置信息.
3.新建一个MsydtConfigSource的类，这个类实现IConfigurationSource接口.为了在启动的时候注入我们自己实现的提供器.
4.给IConfigurationBuilder定义一个AddMsydtConfig的扩展方法，跟.Net Core自带的几个配置源使用风格保持一致。
5.在Program中添加对MsydtConfigBuilderExt类中的扩展方法AddMsydtConfig的调用.
不管什么语言的项目,几乎或多或少都会用到配置文件.
.Net Framework时代我们使用App.config、Web.config，到了.Net Core的时代我们使用appsettings.json，这些我们再熟悉不过了。
然而当前,我们部署.net core项目,很多时候是容器化的,并且很多项目采用微服务架构,这些本地文件配置有的时候就不太合适了
为什么不合适呢?主要有以下几方面:
当你把项目部署到docker后，你会发现要修改一个配置文件变的非常麻烦。你不得不通过宿主机进入容器内部来修改文件，也许容器内还不带vi等编辑工具，连看都不能看，只有更改后重新编译发布镜像或者在容器中安装vi等工具。
我们一般做的是微服务架构,我们通常会启动多个容器实例.一个一个去修改容器的配置,这简直要命.
通常我们需要一些热更新的配置文件.打个比方:有一台邮件服务站点,更换了ip地址,其它调用它的站点要更新配置文件,只能一台一台的去更改配置,然后重新启动站点,才会生效.
4.相同的配置各个站点会冗余配置.比如:Redis服务的地址,各个站点都是访问同一个,但是在各个项目里都要配置一遍.
针对上面这些,不友好的配置体验,以下根据亲身实战,分享给同行从业者,我们一起学习,成长.
温馨提示：看文章前,最好要先去了解.net core中的IConfiguration,尽量先去看看源码.
编程语言:C#
SDK版本:.NET Core2.2
微服务框架:ocelot
上图是我们的微服务架构图.看到的三台Service,就是具体的业务站点,他们都有自己的配置文件,这里只画了三台,实际生产环境,可能是几十台,几百台,所以“配置中心”就诞生了。
配置中心是微服务的基础设施，它对配置进行集中的管理并对内暴露接口，当应用程序需要的时候通过接口读取。配置通常为json模式(为了兼容.net core项目默认的配置文件是Json)，然后通过http接口暴露。
废话不多说直接上解决方案.
NET Core应用启动时主动调用一次配置中心，获取站点所有的配置信息.
新启动NET Core应用能够将自身的IP地址注册到配置中心，便于配置中心配置更改后,通知NET Core应用进行配置热更新.
为了兼容NET Core应用取配置的格式,做到配置文件零侵入要继承ConfigurationProvider类,重写Load()函数,实现从远程配置中心拉取配置信息.
上图是在配置中心管理系统中:添加一条配置信息.
环境标签:Debug(用于应用站点,通过这个标识来获取什么环境的配置)
配置标识:mianshiyidiantong(用于应用站点,通过这个标识来获取具体配置信息)
配置信息:具体的NET Core应用站点的Json配置信息详情.
具体实现,我在CSDN中,总共分为三个章节来实现.
可以直接点连接,跳转过去,看详情:
提示：第一章,虽然实现了应用站点的配置信息,通过配置中心集中管理起来.但是我们还有提高的地方：
例如：
1.应用站点的配置文件,可能存在更改的情况,这个时候,我们在配置中心,更改了,要通知所有使用这个配置的应用站点.要做到热更新,不要动不动就去重启应用站点(对于流量大的应用,这将会带来收益的极大损伤,老板也不允许你这样干,也许2分钟,就会影响上百单的交易).**这在下一篇:微服务配置文件可视化集中管理—第二章**将继续讲解.
网友评论