左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家,骨灰级程序员
立即订阅
40357 人已学习
课程目录
已完结 108 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 | 洞悉技术的本质,享受科技的乐趣
免费
01 | 程序员如何用技术变现(上)
02 | 程序员如何用技术变现(下)
03 | Equifax信息泄露始末
04 | 从Equifax信息泄露看数据安全
05 | 何为技术领导力?
06 | 如何才能拥有技术领导力?
07 | 推荐阅读:每个程序员都该知道的知识
08 | Go语言,Docker和新技术
09 | 答疑解惑:渴望、热情和选择
10 | 如何成为一个大家愿意追随的Leader?
11 | 程序中的错误处理:错误返回码和异常捕捉
12 | 程序中的错误处理:异步编程以及我的最佳实践
13 | 魔数 0x5f3759df
14 | 推荐阅读:机器学习101
15 | 时间管理:同扭曲时间的事儿抗争
16 | 时间管理:如何利用好自己的时间?
17 | 故障处理最佳实践:应对故障
18 | 故障处理最佳实践:故障改进
19 | 答疑解惑:我们应该能够识别的表象和本质
20 | Git协同工作流,你该怎么选?
21 | 分布式系统架构的冰与火
22 | 从亚马逊的实践,谈分布式系统的难点
23 | 分布式系统的技术栈
24 | 分布式系统关键技术:全栈监控
25 | 分布式系统关键技术:服务调度
26 | 分布式系统关键技术:流量与数据调度
27 | 洞悉PaaS平台的本质
28 | 推荐阅读:分布式系统架构经典资料
29 | 推荐阅读:分布式数据调度相关论文
30 | 编程范式游记(1)- 起源
31 | 编程范式游记(2)- 泛型编程
32 | 编程范式游记(3) - 类型系统和泛型的本质
33 | 编程范式游记(4)- 函数式编程
34 | 编程范式游记(5)- 修饰器模式
35 | 编程范式游记(6)- 面向对象编程
36 | 编程范式游记(7)- 基于原型的编程范式
37 | 编程范式游记(8)- Go 语言的委托模式
38 | 编程范式游记(9)- 编程的本质
39 | 编程范式游记(10)- 逻辑编程范式
40 | 编程范式游记(11)- 程序世界里的编程范式
41 | 弹力设计篇之“认识故障和弹力设计”
42 | 弹力设计篇之“隔离设计”
43 | 弹力设计篇之“异步通讯设计”
44 | 弹力设计篇之“幂等性设计”
45 | 弹力设计篇之“服务的状态”
46 | 弹力设计篇之“补偿事务”
47 | 弹力设计篇之“重试设计”
48 | 弹力设计篇之“熔断设计”
49 | 弹力设计篇之“限流设计”
50 | 弹力设计篇之“降级设计”
51 | 弹力设计篇之“弹力设计总结”
52 | 管理设计篇之“分布式锁”
53 | 管理设计篇之“配置中心”
54 | 管理设计篇之“边车模式”
55 | 管理设计篇之“服务网格”
56 | 管理设计篇之“网关模式”
57 | 管理设计篇之“部署升级策略”
58 | 性能设计篇之“缓存”
59 | 性能设计篇之“异步处理”
60 | 性能设计篇之“数据库扩展”
61 | 性能设计篇之“秒杀”
62 | 性能设计篇之“边缘计算”
63 | 区块链技术的本质
64 | 区块链技术细节:哈希算法
65 | 区块链技术细节:加密和挖矿
66 | 区块链技术细节:去中心化的共识机制
67 | 区块链技术细节:智能合约
68 | 区块链技术 - 传统金融和虚拟货币
69 | 程序员练级攻略:开篇词
70 | 程序员练级攻略:零基础启蒙
71 | 程序员练级攻略:正式入门
72 | 程序员练级攻略:程序员修养
73 | 程序员练级攻略:编程语言
74 | 程序员练级攻略:理论学科
75 | 程序员练级攻略:系统知识
76 | 程序员练级攻略:软件设计
77 | 程序员练级攻略:Linux系统、内存和网络
78 | 程序员练级攻略:异步I/O模型和Lock-Free编程
79 | 程序员练级攻略:Java底层知识
80 | 程序员练级攻略:数据库
81 | 程序员练级攻略:分布式架构入门
82 | 程序员练级攻略:分布式架构经典图书和论文
83 | 程序员练级攻略:分布式架构工程设计
84 | 程序员练级攻略:微服务
85 | 程序员练级攻略:容器化和自动化运维
86 | 程序员练级攻略:机器学习和人工智能
87 | 程序员练级攻略:前端基础和底层原理
88 | 程序员练级攻略:前端性能优化和框架
89 | 程序员练级攻略:UI/UX设计
90 | 程序员练级攻略:技术资源集散地
91 | 程序员面试攻略:面试前的准备
92 | 程序员面试攻略:面试中的技巧
93 | 程序员面试攻略:面试风格
94 | 程序员面试攻略:实力才是王中王
95 | 高效学习:端正学习态度
96 | 高效学习:源头、原理和知识地图
97 | 高效学习:深度,归纳和坚持实践
98 | 高效学习:如何学习和阅读代码
99 | 高效学习:面对枯燥和量大的知识
左耳听风
登录|注册

53 | 管理设计篇之“配置中心”

陈皓 2018-04-03
我们知道,除了代码之外,软件还有一些配置信息,比如数据库的用户名和密码,还有一些我们不想写死在代码里的东西,像线程池大小、队列长度等运行参数,以及日志级别、算法策略等,还有一些是软件运行环境的参数,如 Java 的内存大小,应用启动的参数,包括操作系统的一些参数配置……
所有这些东西,我们都叫做软件配置。以前,我们把软件配置写在一个配置文件中,就像 Windows 下的 ini 文件,或是 Linux 下的 conf 文件。然而,在分布式系统下,这样的方式就变得非常不好管理,并容易出错。于是,为了便于管理,我们引入了一个集中式的配置管理系统,这就是配置中心的由来。
现在,软件的配置中心是分布式系统的一个必要组件。这个系统听起来很简单,但其实并不是。我见过好多公司的配置中心,但是我觉得做得都不好,所以,想写下这篇文章给你一些借鉴。

配置中心的设计

区分软件的配置

首先,我们要区分软件的配置,软件配置的区分有多种方式。
有一种方式是把软件的配置分成静态配置和动态配置。所谓静态配置其实就是在软件启动时的一些配置,运行时基本不会进行修改,也可以理解为是环境或软件初始化时需要用到的配置。
例如,操作系统的网络配置,软件运行时 Docker 进程的配置,这些配置在软件环境初始化时就确定了,未来基本不会修改了。而所谓动态配置其实就是软件运行时的一些配置,在运行时会被修改。比如,日志级别、降级开关、活动开关。
当然,我们这里的内容主要针对动态配置的管理。
对于动态配置的管理,我们还要做好区分。一般来说,会有三个区分的维度。
按运行环境分。一般来说,会有开发环境、测试环境、预发环境、生产环境。这些环境上的运行配置都不完全一样,但是理论来说,应该是大同小异的。
按依赖区分。一种是依赖配置,一种是不依赖的内部配置。比如,外部依赖的 MySQL 或 Redis 的连接配置。还有一种完全是自己内部的配置。
按层次分。就像云计算一样,配置也可以分成 IaaS、PaaS、SaaS 三层。基础层的配置是操作系统的配置,中间平台层的配置是中间件的配置,如 Tomcat 的配置,上层软件层的配置是应用自己的配置。
这些分类方式其实是为了更好地管理我们的配置项。小公司无所谓,而当一个公司变大了以后了,如果这些东西没有被很好地管理起来,那么会增加太多系统维护的复杂度。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《左耳听风》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(16)

  • 曾经的十字镐
    耗子哥这篇文章讲的非常好也非常全,但是我还想发表一下我的看法,我觉得配置中心应该根据实际情况来选择,我见过好多团队,其项目非常简单,就是一个分布式项目,4-5个模块,还搞了一个配置中心,实在有些重,我们项目也不大我使用mysql加定时拉取就搞定了,要搞清楚使用配置中心的目的,不要盲目的实用配置中心,这样你的系统就变得复杂了。
    2018-04-25
    16
  • 繁泽
    耗子叔您好,请问 GitHub 上有没有一些不错的契合您写的设计思路的项目代码能推荐参考呢?
    2018-04-24
    15
  • 约书亚
    我团队架构之前考虑过上配置中心,主要是应用配置方向,调研过携程Apollo,后反复论证暂时搁置,在期间我的思考如下:
    1. 动静态的分类比较相对,实际开发常修改的配置大多是性能微调的参数和日志级别等,而前者应减少在生产环境的尝试。其他变更,因微服务的自动化技术,修改后重发布显得问题不大。通用/独有的中间件地址发生变更(比如failover)时,看起来很需要配置中心,但现在有各种流量调度技术
    2. 很多配置变更需重建上下文,此类功能难写,框架少,而且担心在重新构建应用程序上下文期间带来服务性能下降。我们Java用SpringBoot,无以上问题...但如没有框架保障,还不如重发布,利用滚动更新+流量调度保证服务可用性
    3. 这些配置是否还要出现在源代码配置文件中?如果是,没想好线上修改的配置项怎么保证同步到源代码。如果否,那上新服务和配置变更操作总有先后,要么配置细分小版本,每次服务发布都不同,要么有个灰度环境

    以上为我们的情况,其实答案在皓哥文章中都有,但落地还需细节,望各位给出建议
    2018-04-24
    6
  • 忙里偷闲
    这篇文章对于边车方式实现服务网格的思路相当清晰,如果要找对于这种思路的实现方案的话,kubernetes的istio应该是最贴近的实现。

    作者回复: 是的

    2018-06-14
    1
  • Field Li
    配置应该还是放在文件里,然后把文件推到agent上,每个机器本地存盘,这样即使配置中心挂了 服务依然可以从本地获取配置
    2018-05-27
    1
  • 龚极客
    请问下耗子哥,如果用docker镜像来管理,需要把配置文件打到包里吗?这样部署容易了,但是这样我需要开发,测试,线上三个包,感觉跟docker一套环境的初衷相违背
    2018-04-26
    1
  • 蜗牛
    边车这个模式是跟着Application 走的,如果一台机器有多个应用就会有多个。既然是和业务无关的,是不是跟着机器走比较好呢。当然如果配合docker的话那就无所谓了。
    2019-07-21
  • edisonhuang
    分布式系统需要一个配置中心来管理软件的配置,配置的分类有静态和动态,按运行环境分类,按照依赖分类,按照层次分类IAAS,PAAS,SAAS等。
    配置中心的设计重点是规范化配置,可以理解为配置治理,让不同角色的人负责不同层级的配置管理,同时保证配置是选择式而非输入式的
    2019-07-16
  • if err ≠ nil { }
    配置中心一般会有个集群去选举吧,不然挂了,就没法用。
    2019-06-28
  • godtrue
    我们有一个UCC,日志开关,业务开关,rpc开关等都通过它来控制,和应用密切相关的都放在了发布系统。
    2019-02-08
  • 小新是也
    我觉得一般来说apollo够用了
    2018-11-25
  • neohope
    浩哥,我想请教一下,一般会把数据库链配置做成动态配置吗?我们现在数据库配置没能做到动态修改配置,只能重启服务。
    前面几个的项目用了百度的配置中心,和spring的结合是不错,但整体框架来说感觉有些笨重。
    另外,spring cloud提供的配置是基于github的,国内不是很合用,不知道大家有没有找到好的实现呢?

    作者回复: 数据库一般入会,因为大关键了。spring的配置是git的,也好也不好。一般来说都是自己实现

    2018-06-24
  • jerry
    没弄动态配置,把java的配置文件抽成配置模板,具体的配置值放到数据库的了,通过web进行增删改查,各个环境通过一个python脚本生成对应环境的配置文件 并发布到对应环境的机器上,脚本里实现了一个配置依赖,在一些环境里共享一些基础配置
    2018-05-31
  • 121373628
    我们公司配置中心的使用分为业务相关配置和运维相关配置(Mq,zk,db相关的配置)。运维相关配置放在配置中心,开发人员无权操作。业务相关配置放在应用包里。然后发布通过统一发布系统发布。整个应用发布过程无需运维参与。比全部配置放配置中心,然后线上配置都需要运维修改的模式。效率提高很多。因为运维并不了解具体业务以及业务配置。运维操作更容易出错。在应用包里,可以开发环境就验证线上环境配置。不会出现配置多一个空格这种细小错误。导致上线才暴露问题。个人体会。
    2018-05-19
  • 缘妙不可言
    请问文中的admin api是什么意思,在sdk使用中是什么样的角色呢
    2018-04-27
  • bing
    我们也有类似的配置中心服务,但是有一个担心,几乎所有有效配置按照设计都放在了配置中心系统上,如果配置系统挂掉,或者发布时有数据请求,怎么处理,这个是我们的担心点
    2018-04-25
收起评论
16
返回
顶部