53 | 管理设计：配置中心
陈皓
该思维导图由 AI 生成，仅供参考
你好，我是陈皓，网名左耳朵耗子。
我们知道，除了代码之外，软件还有一些配置信息，比如数据库的用户名和密码，还有一些我们不想写死在代码里的东西，像线程池大小、队列长度等运行参数，以及日志级别、算法策略等，还有一些是软件运行环境的参数，如 Java 的内存大小，应用启动的参数，包括操作系统的一些参数配置……
所有这些东西，我们都叫做软件配置。以前，我们把软件配置写在一个配置文件中，就像 Windows 下的 ini 文件，或是 Linux 下的 conf 文件。然而，在分布式系统下，这样的方式就变得非常不好管理，并容易出错。于是，为了便于管理，我们引入了一个集中式的配置管理系统，这就是配置中心的由来。
现在，软件的配置中心是分布式系统的一个必要组件。这个系统听起来很简单，但其实并不是。我见过好多公司的配置中心，但是我觉得做得都不好，所以，想写下这篇文章给你一些借鉴。
配置中心的设计
区分软件的配置
首先，我们要区分软件的配置，软件配置的区分有多种方式。
有一种方式是把软件的配置分成静态配置和动态配置。所谓静态配置其实就是在软件启动时的一些配置，运行时基本不会进行修改，也可以理解为是环境或软件初始化时需要用到的配置。
例如，操作系统的网络配置，软件运行时 Docker 进程的配置，这些配置在软件环境初始化时就确定了，未来基本不会修改了。而所谓动态配置其实就是软件运行时的一些配置，在运行时会被修改。比如，日志级别、降级开关、活动开关。
当然，我们这里的内容主要针对动态配置的管理。
对于动态配置的管理，我们还要做好区分。一般来说，会有三个区分的维度。
按运行环境分。一般来说，会有开发环境、测试环境、预发环境、生产环境。这些环境上的运行配置都不完全一样，但是理论来说，应该是大同小异的。
按依赖区分。一种是依赖配置，一种是不依赖的内部配置。比如，外部依赖的 MySQL 或 Redis 的连接配置。还有一种完全是自己内部的配置。
按层次分。就像云计算一样，配置也可以分成 IaaS、PaaS、SaaS 三层。基础层的配置是操作系统的配置，中间平台层的配置是中间件的配置，如 Tomcat 的配置，上层软件层的配置是应用自己的配置。
这些分类方式其实是为了更好地管理我们的配置项。小公司无所谓，而当一个公司变大了以后，如果这些东西没有被很好地管理起来，那么会增加太多系统维护的复杂度。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
分布式系统设计模式中的配置中心是分布式系统中不可或缺的组件。本文详细介绍了配置项的分类、配置中心的模型和架构，为读者提供了设计模式和架构实现的参考。 首先，文章区分了软件配置为静态配置和动态配置，并按照运行环境、依赖和层次进行了分类。其次，设计了软件配置模型，将配置分为操作系统层、平台层和应用层，并提出了配置管理工具的需求。最后，讨论了配置中心的架构，包括配置变更通知、配置变更控制器的部署位置、平台层配置变更的处理方式等。 文章强调了配置中心的设计重点，包括统一和标准化软件的配置项、配置更新的事务处理、配置版本与软件版本的对应关系、配置更新控制器的功能等。通过详细的设计和架构思路，为读者提供了配置中心的设计模式和架构实现的参考，对于分布式系统的配置管理具有一定的指导意义。 总之，本文通过对配置中心的设计重点和架构的详细介绍，为读者提供了在分布式系统中实现配置中心的指导和参考，对于需要进行分布式系统配置管理的技术人员具有重要的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《左耳听风》，新⼈⾸单¥98
《左耳听风》，新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(29)
- 最新
- 精选
忙里偷闲这篇文章对于边车方式实现服务网格的思路相当清晰，如果要找对于这种思路的实现方案的话，kubernetes的istio应该是最贴近的实现。作者回复: 是的
2018-06-144
neohope浩哥，我想请教一下，一般会把数据库链配置做成动态配置吗？我们现在数据库配置没能做到动态修改配置，只能重启服务。 前面几个的项目用了百度的配置中心，和spring的结合是不错，但整体框架来说感觉有些笨重。 另外，spring cloud提供的配置是基于github的，国内不是很合用，不知道大家有没有找到好的实现呢？作者回复: 数据库一般入会，因为大关键了。spring的配置是git的，也好也不好。一般来说都是自己实现
2018-06-242
曾经的十字镐耗子哥这篇文章讲的非常好也非常全，但是我还想发表一下我的看法，我觉得配置中心应该根据实际情况来选择，我见过好多团队，其项目非常简单，就是一个分布式项目，4-5个模块，还搞了一个配置中心，实在有些重，我们项目也不大我使用mysql加定时拉取就搞定了，要搞清楚使用配置中心的目的，不要盲目的实用配置中心，这样你的系统就变得复杂了。2018-04-25144
繁泽耗子叔您好，请问 GitHub 上有没有一些不错的契合您写的设计思路的项目代码能推荐参考呢？2018-04-24119
约书亚我团队架构之前考虑过上配置中心，主要是应用配置方向，调研过携程Apollo,后反复论证暂时搁置，在期间我的思考如下： 1. 动静态的分类比较相对，实际开发常修改的配置大多是性能微调的参数和日志级别等，而前者应减少在生产环境的尝试。其他变更，因微服务的自动化技术，修改后重发布显得问题不大。通用/独有的中间件地址发生变更（比如failover）时，看起来很需要配置中心，但现在有各种流量调度技术 2. 很多配置变更需重建上下文，此类功能难写，框架少，而且担心在重新构建应用程序上下文期间带来服务性能下降。我们Java用SpringBoot，无以上问题...但如没有框架保障，还不如重发布，利用滚动更新+流量调度保证服务可用性 3. 这些配置是否还要出现在源代码配置文件中？如果是，没想好线上修改的配置项怎么保证同步到源代码。如果否，那上新服务和配置变更操作总有先后，要么配置细分小版本，每次服务发布都不同，要么有个灰度环境 以上为我们的情况，其实答案在皓哥文章中都有，但落地还需细节，望各位给出建议2018-04-24116
Field Li配置应该还是放在文件里，然后把文件推到agent上，每个机器本地存盘，这样即使配置中心挂了 服务依然可以从本地获取配置2018-05-2710
迷宫中的将军不太推荐使用配置中心的方式，最好的就是和代码仓库一起，静态管理。 这种开发以及维护的成本比较高。同时生产环境上配置的变化开发人员不可见，不太符合IaC的原则。2021-01-2915
121373628我们公司配置中心的使用分为业务相关配置和运维相关配置(Mq,zk,db相关的配置)。运维相关配置放在配置中心，开发人员无权操作。业务相关配置放在应用包里。然后发布通过统一发布系统发布。整个应用发布过程无需运维参与。比全部配置放配置中心，然后线上配置都需要运维修改的模式。效率提高很多。因为运维并不了解具体业务以及业务配置。运维操作更容易出错。在应用包里，可以开发环境就验证线上环境配置。不会出现配置多一个空格这种细小错误。导致上线才暴露问题。个人体会。2018-05-1915
亚配置中心可以使用zookeeper的状态来通知各个业务进程某个配置文件有变化，通知时只告知文件内容有变化，具体数据让业务进程重新去配置中心拉取。我们项目目前 是这样实现的。2020-04-263
知行合一配置中心设计的好的话可以做到灵活配置和版本控制等，而且会有本地缓存或者写文件，即使配置中心挂了，服务也能读取本地的配置保证可用性2020-01-102
收起评论
