33-配置管理：成千上万的配置项要如何管理？_For_group_share1
需积分: 0 76 浏览量
2022-08-03
19:02:01
上传
评论
收藏 242KB PDF 举报
33-配置管理：成千上万的配置项要如何管理？33-配置管理：成千上万的配置项要如何管理？
你好，我是唐扬。
相信在实际⼯作中，提及性能优化你会想到代码优化，但是实际上有些性能优化可能只需要调整⼀些配置参
数就可以搞定了。为什么这么说呢？我给你举⼏个例⼦：
你可以认为配置是管理你系统的⼯具，在你的垂直电商系统中，⼀定会有⾮常多的配置项，⽐如数据库的地
址、请求HTTP服务的域名、本地内存最⼤缓存数量等等。
那么，你要如何对这些配置项做管理呢？管理的过程中要注意哪些事情呢？
如何对配置进⾏管理呢？如何对配置进⾏管理呢？
配置管理由来已久，在Linux系统中就提供了⼤量的配置项，你可以依据⾃⾝业务的实际情况，动态地对系
统功能做调整。⽐如，你可以通过修改dirty_writeback_centisecs参数的数值，调整PageCache中脏数据
刷新到磁盘上的频率；你也可以通过修改tcp_max_syn_backlog参数的值，来调整未建⽴连接队列的⻓
度。⽽你既可以通过修改配置⽂件并且重启服务器来让配置⽣效，也可以通过sysctl命令来动态地调整，让
配置即时⽣效。
那么在开发应⽤的时候，都有哪些管理配置的⽅式呢？我觉得主要有两种：
以电商系统为例，你和你的团队在刚开始开发垂直电商系统时，为了加快产品的研发速度，⼤概率不会注意
配置管理的问题，会⾃然⽽然地把配置项和代码写在⼀起。但是随着配置项越来越多，为了更好地对配置项
进⾏管理，同时避免修改配置项后还要重新对代码做编译，你选择把配置项独⽴成单独的⽂件（⽂件可以是
properties格式、xml格式或yaml格式）。不过，这些⽂件还是会和⼯程⼀起打包部署，只是更改配置后不
需要重新编译代码了。
随后，你很快发现了⼀个问题：随后，你很快发现了⼀个问题：虽然把配置拆分了出来，但是由于配置还是和代码打包在⼀起，如果要更改
⼀个配置还是需要重新打包，这样⽆疑会增加打包的时间。于是，你考虑把配置写到单独的⽬录中，这样，
修改配置就不需要再重新打包了（不过，由于配置并不能够实时⽣效，所以想让配置⽣效，还是需要重启服
务）。
我们⼀般使⽤的基础组件，⽐如Tomcat、Nginx，都是采⽤上⾯这种配置⽂件的⽅式来管理配置项的，⽽在
Linux系统中，我提到的tcp_max_syn_backlog就可以配置在/etc/sysctl.conf中。
这⾥，我需要强调⼀点，我们通常会把配置⽂件存储的⽬录标准化为特定的⽬录。这⾥，我需要强调⼀点，我们通常会把配置⽂件存储的⽬录标准化为特定的⽬录。⽐如，都配置
成/data/confs⽬录，然后把配置项使⽤Git等代码仓库管理起来。这样，在增加新的机器时，在机器初始化
脚本中只需要创建这个⽬录，再从Git中拉取配置就可以了。这是⼀个标准化的过程，可以避免在启动应⽤
你可以调整配置的超时时间让请求快速失败，防⽌系统的雪崩，提升系统的可⽤性；
你还可以调整HTTP客⼾端连接池的⼤⼩，来提升调⽤第三⽅HTTP服务的并⾏处理能⼒，从⽽提升系统的
性能。
⼀种是通过配置⽂件来管理；
另⼀种是使⽤配置中⼼来管理。
评论0