Apollo在设计之初就考虑到了公共组件的配置场景，下面摘抄一段之前在infoq上发表的[文章](https://mp.weixin.qq.com/s/iDmYJre_ULEIxuliu1EbIQ)：
> 公共组件是指那些发布给其它应用使用的客户端代码，比如 RPC 客户端、DAL 客户端等。 > 这类组件一般是由单独的团队（如中间件团队）开发、维护，但是运行时是在业务实际应用内的，所以本质上可以认为是应用的一部分。 > 这类组件的特殊之处在于大部分的应用都会直接使用中间件团队提供的默认值，少部分的应用需要根据自己的实际情况对默认值进行调整。 > 比如数据库连接池的最小空闲连接数量（minimumIdle），出于对数据库资源的保护，DBA 要求将全公司默认的 minimumIdle 设为 > 1，对大部分的应用可能都适用，不过有些核心 / 高流量应用可能觉得太小，需要设为 10。 > 针对这种情况，可以借助于 Apollo 提供的 Namespace 实现： > > 1. 中间件团队创建一个名为dal的公共 Namespace，设置全公司的数据库连接池默认配置 > ```properties > minimumIdle = 1 > maximumPoolSize = 20 > ``` > 2. dal 组件的代码会读取dal公共 Namespace 的配置 > 3. 对大部分的应用由于默认配置已经适用，所以不用做任何事情 > 4. 对于少量核心 / 高流量应用如果需要调整 minimumIdle 的值，只需要关联dal公共 > Namespace，然后对需要覆盖的配置做调整即可，调整后的配置仅对该应用自己生效 > ```properties > minimumIdle = 10 > ``` >  > 通过这种方式的好处是不管是中间件团队，还是应用开发，都可以灵活地动态调整公共组件的配置。 更多说明可以参考[Apollo核心概念之“Namespace”](https://github.com/ctripcorp/apollo/wiki/Apollo%E6%A0%B8%E5%BF%83%E6%A6%82%E5%BF%B5%E4%B9%8B%E2%80%9CNamespace%E2%80%9D) 所以，以apollo为例，对于一家公司内理想的配置使用方式可能是下面这样子的： 1. 公共团队创建一个公共的namespace - dubbo，并设置全公司默认值 ``` dubbo.registry.address=zookeeper://1.2.3.4:2181 dubbo.consumer.timeout=1000 ``` 2. 所有dubbo的服务端和客户端引入dubbo-configcenter-apollo，并加入类似如下配置（`106.12.25.204:8080`为apollo meta server地址，支持逗号分隔填写多个，一般建议配置slb地址） ```xml <dubbo:config-center address="apollo://106.12.25.204:8080"/> ``` 3. 对于大部分的应用其实不需要在apollo做任何额外配置就能正常工作 4. 对于少量应用，比如有些觉得1秒的timeout太小了，需要设大一些，那么只要在自己项目中关联一下公共的dubbo namespace，然后覆盖dubbo.consumer.timeout即可，样例如下：  所以，apollo的模型是倾向于把namespace类比为properties文件，包含了逻辑上的一组配置，同时对于公共配置，支持通过界面直观的操作单个/多个配置的自定义。 按照目前dubbo的组织方式（把dubbo相关配置作为一个配置项管理）也能实现上述功能，不过对于用户使用（配置或覆盖）可能就不那么直观了。 鉴于dubbo需要接入更多配置中心，所以在模型上做一层抽象是合理的，不过也希望能讨论下是否有可能使这个抽象也能更好地支持类似apollo这样的模型。 [ Full content available at: https://github.com/apache/incubator-dubbo/issues/3266 ] This message was relayed via gitbox.apache.org for [email protected]
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
