- 2018-12-26apollo 这个看着不错，我们可以看看
我们一般把配置分为两类， 一类是环境相关的全局配置，另一类是程序相关的局部配置。
局部配置一般放在代码包里跟着代码走， 一般情况下，全局配置是部署的时候需要提供的，比如指定部署的机器， 端口等，代码配置一般是不需要变更的，如果变更，配置中心指定要变更的项目，推到机器上， 或者本地有配置agent 服务的话，也能定期pull 配置中心的该变更项 。 2 
2018-07-29阿波罗相比disconf有哪些优势呢作者回复: 可以参考以下文档
https://github.com/ctripcorp/apollo/wiki/FAQ#10-apollo和disconf相比有什么优点 2
2018-09-25请问，像nginx，以及docker这样的，是不是都可以用配置中心来管理配置？
那我理解的，就是只要是文件形式存在于应用程序里的配置，都可以修改吗？作者回复: 也不能这么说，我们使用配置中心主要是为了解决业务逻辑的配置，需要中间件配合，你提到的有些系统本身很完整比如k8s，自己有配置方案，而nginx是否可以使用你选择的中间件才是问题，当然以这个思路做二次开发都不是问题
1
2020-01-22老师，我们用啦Apollo，但是再修改配置后。服务重启才能生效，这是我们那个地方没有配置好吗？
2019-10-29请教老师个问题。
我们测试环境有五套，例如叫：test1、test2、test3、test4、test5。
现在是这五套环境用的五个IDC，就是每个环境不同的配置集群。可是这五个环境的配置项，大部分是相同的，只有四五个是各环境不同的。
有没有办法，让五个环境的某些配置项共用一套配置，另外一些配置项再加载不同的配置集群。
2019-08-07你好 俊哥 好亲切 我曾在携程短暂的待过一段时间 现在遇到一个问题：在线上发布时 我们不止一次的把测试环境的地址配置到了线上，请问针对这个问题 你有什么好的建议吗？作者回复: 优先使用Apollo这样的配置中心，数据结构支持一个key分属不同环境的不同value，读取时根据环境值获取
2018-12-22按照《持续交付》书中的说法，把每个环境的配置文件作为代码在git中维护是最好的办法！作者回复:
我个人认为这种说法已经过时了。可以参看专栏中的相关内容。代码版本和配置应该解耦，否则会产生两种结果，一，不同环境的版本不对应；或者版本冗余
2018-08-12apollo内置了高可用注册中心，为什么不开放端口，也能当注册中心来用？作者回复: Apollo有一个自用的注册中心功能，确实可以用，但毕竟不是专门做这块的服务，功能就较简单，有些能力可能也是缺失的
2018-07-30配置中线的权限问题怎么解决？比如第三方的key，和 普通配置 如果让不同的人员管理不同的配置？作者回复: 配置本身可以属于不同的category，对这层做权限即可，当然你问一个key是否可以属于多个category，那就看你的具体设计了
2018-07-30以Java为例，JVM参数，应用的端口等等应该放在哪里呢？作者回复: 这是个好问题，jvm参数有很多特殊性，包括冲突配置等，目前我们的想法是独立一套单独的服务做这块，服务的生命周期在编译打包。但还没完全实现
2018-07-28谢谢！这一节的内容对我们项目现在正有用！我们项目现在有一些与业务强关联的硬编码，而且有上百处，现在要对不同的客户即不同的生产环境进行部署，所以必须把硬编码改成配置，请问这种情况适合用配置中心来进行管理吗？期待您的回复作者回复: 可以再看一下上一讲的内容，联系起来使用配置中心，是很合适的解决方案