3.5. 配置文件

配置文件存在于 protected/Config 目录下,在里面你会看到一堆的 common-xxx.cfg, shop-xxx.cfg, manage-xxx.cfg 文件。文件挺多,很多名字看着还很像,你一看就容易晕了不知道从哪里下手。恩,是的,我一开始也有这样的感受,等你弄明白这些文件名的规则之后这些感受最终会变成一种"享受"。这些文件的名字清晰的告诉了你,你需要的配置项在哪个文件里面。

env.cfg

注意观察,这个文件很特别,没有和它名字类似的文件,对了,这就是整个配置的"入口"

env.cfg文件的内容. 

[globals]

## 切换系统不同的运行环境配置,系统会根据这个设置加载不同的环境配置文件   {配置文件}-{env}.cfg
## 这里的值随你定义,系统缺省可以是 prod|dev-linux|dev-win
sysConfig[env]="prod"

我们的商城系统是 Shop,现在 env.cfg 里面设置的是 prod ,意味着商城现在使用的配置文件是 shop-prod.cfg。如果 env.cfg 里面设置的是 dev-linux,那么现在你的 Shop 跑的配置文件就是 shop-dev-linux.cfg,这下你能看明白其它的文件名了吗?

一般系统开发都会有好几个环境,比如你自己的电脑(开发环境 dev),公司内部的测试服务器(测试环境 qa,多人开发并且都往上面提交自己的代码),公司网站正式的服务器(生产环境 prod)。不同的环境对应的一些配置也会不一样,最简单的比如数据库配置就不一样:

由此推广,你的支付宝配置的 AppId、AppKey,你的QQ登陆配置的 AppId、AppKey,你的上传文件目录的配置 …。对于这种不同环境不同配置最土鳖的方法当然就是保存多个配置文件,然后当你发布到 prod 的时候,就把对应保存的配置文件改名覆盖到 config.xxx 里面,这种方法 够土、够傻 当然也确实够用。

我们希望用一种更加简单有效又正规的方法来处理这个问题,这就是 env.cfg 文件的作用,切换系统配置的适合不再需要"改名覆盖文件",而是直接修改 env.cfg 里面的参数值,整个环境配置就完成了切换。采用 env.cfg 有利于分布式系统的统一切换,几百台服务器你一个一个去改文件名覆盖?

所以,shop.cfg 是 shop 的配置(不依赖于环境的配置,比如商城名字),shop-prod.cfg 是对应环境的具体配置(比如数据库配置)。如果两者有重复的定义,后面的定义会覆盖前面的定义。

图 3.3. Shop配置文件环境1

dev_basic_config_shop_env_config1.png

common.cfg

注意观察,这个文件名很特别 "common" ,是的,这里面是一些公用设置。

我们有多个系统 Shop、Mobile、Manage、Supplier,这些系统会共享一些相同的设置,比如网站名称 "棒主妇开源" ,比如数据库是同一个。这些相同的设置自然没必要在每个系统里面都重复设置一份,所以我们定义了 common.cfg 用来保存这些 "公用" 的设置。我们只需要在 common.cfg 中定义一次,所有系统就都可以使用了。

问题又来了,如果 common.cfg 中定义了 DbHost="aaaaa",同时我在 Shop 中也定义了 DbHost="bbbbb",这岂不是冲突了? 不,不冲突,我们允许甚至鼓励这种配置覆盖,你可以认为 common.cfg 中定义的是 "缺省值",而你可以在 shop.cfg 中覆盖这些 "缺省值"。事实上,配置可以重复定义N次,每一次都覆盖上一次的定义,真正有效的是 "最后一次的配置"。所以完整的文件配置图为:

图 3.4. Shop配置文件环境2

dev_basic_config_shop_env_config2.png

了解配置文件的原理是后面读懂代码的基础,如果到这里还是不明白配置文件是怎么工作的,请重新再阅读一次。可以尝试修改配置文件中的一些内容,自己做做实验看看。

[注意]

整个系统的数据库配置在 common-prod.cfg 里面,因为是各个系统公用的嘛!^_^ 你再顺便看看 common-dev-linux.cfg 和 common-dev-win.cfg,你懂了吗?