微服务修炼之配置中心

最新推荐文章于 2024-06-10 14:37:43 发布

夜里慢慢行456

最新推荐文章于 2024-06-10 14:37:43 发布

阅读量259

点赞数

分类专栏：微服务

本文链接：https://blog.csdn.net/u013257767/article/details/107234065

版权

微服务专栏收录该内容

34 篇文章 0 订阅

订阅专栏

文章目录

概念

在单体应用中，我们常常将一些配置数据放在配置文件中进行集中统一管理，避免硬编码造成频繁发布。比如，数据库，redis，线程池，等等。常见的windows中的ini文件，linux系统中的conf，springboot工程中的application.properties。但是在分布式系统中，经常遇到的场景是多个系统共享同一份数据，这种情况下再通过文件配置处理，显得繁琐易错。为了便于管理引入集中式的处理系统-----配置中心
配置中心可以被认为是一个个的键值对。

组织方式
按环境：
像阿里的configserver，分为日常环境，预发环境，生成环境，灰度环境等。
按依赖
系统内部的，如文件上传大小，接口重发次数等。外部的中间件如redis，mysql。
按层次
基础层，中间件层，应用层

配置中心的出现解决的是配置信息的组织管理问题。
那么简单点的一个redis能不能做分布式的配置中心呢？

关注点

数据的从属管理
变更管理
生效时机

设计思路

前面提到了配置中心管理的其实是一个个的键值对，那么什么情况下的数据应该放在配置中心，什么放在服务发现，什么放在应用中呢？
耗子叔有提到这一点：

我们的配置参数中，如果有外部服务依赖的配置，强烈建议不要放在配置中心里，而要放在服务发现系统中。因为一方面这在语义上更清楚一些，另外，这样会减少因为运行不同环境而导致配置不同的差异性（如测试环境和生产环境的不同）。
s
对于不同运行环境中配置的差异来说，比如在开发环境和测试环境下，日志级别是 Debug 级，对于生产环境则是 Warning 或 Error 级，因为环境的不一样，会导致我们需要不同的配置项的值。这点需要考虑到。
还有，我们的配置需要有一个整体的版本管理，每次变动都能将版本差异记录下来。当然，如果可能，最好能和软件的版本号做关联。

在这里插入图片描述
自然的我们会想到要实现一个配置中心，可以使用的技术包括，配置存储（版本关联，如git，svn），发布订阅模式，push/pull模式。