11 | “配置”是把双刃剑，带你了解各种配置方法

王潇俊

很多人分不清配置和配置管理，但其实它们是完全不同的概念。
配置管理： 是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。 它的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期的各个阶段都能得到精确的产品配置信息。
配置： 是指独立于程序之外，但又对程序产生作用的可配变量。也就是说，同一份代码在不同的配置下，会产生不同的运行结果。
从上面的定义中，你可以看到配置和配置管理有着本质上的不同：配置管理服务于软件研发过程，而配置则服务于程序本身。
作为一名程序员，开发时经常要面对不同的运行环境：开发环境、测试环境、生产环境、内网环境、外网环境等等。不同的环境，相关的配置一般不一样，比如数据源配置、日志文件配置，以及一些软件运行过程中的基本配置等。
另外，你也会遇到一些业务上的，以及逻辑上的配置。比如，针对不同地域采取不同的计费逻辑，计费逻辑又要根据这些地域的需要随时调整。
如果我们把这些信息都硬编码在代码里，结果就是：每次发布因为环境不同，或者业务逻辑的调整，都要修改代码。而代码一旦被修改，就需要完整的测试，那么变更的代价将是巨大的。
因此，我们往往会通过“配置”来解决这些问题。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《持续交付 36 讲》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(14)

最新
精选

Tank
阿波罗相比disconf有哪些优势呢
作者回复: 可以参考以下文档 https://github.com/ctripcorp/apollo/wiki/FAQ#10-apollo和disconf相比有什么优点

4
华华
按照《持续交付》书中的说法，把每个环境的配置文件作为代码在git中维护是最好的办法！
作者回复: 我个人认为这种说法已经过时了。可以参看专栏中的相关内容。代码版本和配置应该解耦，否则会产生两种结果，一，不同环境的版本不对应；或者版本冗余
2
2
.
请问，像nginx，以及docker这样的，是不是都可以用配置中心来管理配置？那我理解的，就是只要是文件形式存在于应用程序里的配置，都可以修改吗？
作者回复: 也不能这么说，我们使用配置中心主要是为了解决业务逻辑的配置，需要中间件配合，你提到的有些系统本身很完整比如k8s，自己有配置方案，而nginx是否可以使用你选择的中间件才是问题，当然以这个思路做二次开发都不是问题

2
陈sir
你好俊哥好亲切我曾在携程短暂的待过一段时间现在遇到一个问题：在线上发布时我们不止一次的把测试环境的地址配置到了线上，请问针对这个问题你有什么好的建议吗？
作者回复: 优先使用Apollo这样的配置中心，数据结构支持一个key分属不同环境的不同value，读取时根据环境值获取

1
付盼星
apollo内置了高可用注册中心，为什么不开放端口，也能当注册中心来用？
作者回复: Apollo有一个自用的注册中心功能，确实可以用，但毕竟不是专门做这块的服务，功能就较简单，有些能力可能也是缺失的


海水
配置中线的权限问题怎么解决？比如第三方的key，和普通配置如果让不同的人员管理不同的配置？
作者回复: 配置本身可以属于不同的category，对这层做权限即可，当然你问一个key是否可以属于多个category，那就看你的具体设计了


祺超
以Java为例，JVM参数，应用的端口等等应该放在哪里呢？
作者回复: 这是个好问题，jvm参数有很多特殊性，包括冲突配置等，目前我们的想法是独立一套单独的服务做这块，服务的生命周期在编译打包。但还没完全实现


刘京城
谢谢！这一节的内容对我们项目现在正有用！我们项目现在有一些与业务强关联的硬编码，而且有上百处，现在要对不同的客户即不同的生产环境进行部署，所以必须把硬编码改成配置，请问这种情况适合用配置中心来进行管理吗？期待您的回复
作者回复: 可以再看一下上一讲的内容，联系起来使用配置中心，是很合适的解决方案


小寞子。(≥3≤)
我们全栈都在aws。 serverless架构。所有业务配置放在dynamodb. 当时也没有仔细想。现在一看这不就是配置中心么。。

3
戴斌
我们是使用gradle在构建的时候传入参数进行构建XX环境的包，构建出来的包包含了特定环境的配置。这种方式每次修改配置都需要构建、发布，而且，每个环境都要做构建。配置中心是我们一直想推进的方式，应该可以提高我们工作效率。

2

收起评论