上一章 文档首页 下一章
Experience by itself teaches nothing... Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence, without theory, there is no learning. – Edwards Deming
1.16.1 配置的简单读取
通常，我们会有以下三个配置文件：
dogstar@ubuntu:Config$ tree
.
├── app.php
├── dbs.php
└── sys.php
其中app.php为项目应用配置；dbs.php为分布式存储的数据库配置；sys.php为不同环境下的系统配置。
在入口文件，注册配置组件服务后：
//$ vim ./Public/init.php
//配置
DI()->config = new PhalApi_Config_File(API_ROOT . '/Config');假设有这样的app.php配置：
return array(
'version' => '1.1.1',
'email' => array(
'address' => 'chanzonghuang@gmail.com',
);
);
我们就可以分别这样根据需要获取配置：
//app.php里面的全部配置
DI()->config->get('app');
//app.php里面的单个配置
DI()->config->get('app.version'); //返回：1.1.1
//app.php里面的多级配置
DI()->config->get('app.email.address'); //返回：'chanzonghuang@gmail.com'其他配置文件类似，你也可以随意添加新的配置文件。
1.16.2 内外环境配置管理的策略
可以说，在项目开发中，除了我们的代码、数据和文档外，配置也是一块相当重要的组成部分，而且占据着非常重要的位置。最为明显的是，如果配置一旦出错，就很可能影响到整个系统的运行，并且远比修改代码再上线发布速度快（假设我们不用文件存储配置而是以分布式存储在各服务器内存中）。
但这里将讨论另外一个同样重要的问题，即： 不同环境下不同配置的管理和切换 。
现在将不同的策略分说如下。
(1)支持整包发布的环境变量配置
此种策略的主要方法就是在PHP代码中读取php-fpm中的ENV环境配置，再对应到linux环境下的profile环境变量，即：
PHP代码 --> $_ENV环境配置 --> Linux服务器环境变量/etc/profile例如：
<?php
return array(
/**
* DB数据库服务器集群
*/
'servers' => array(
'db_demo' => array( //服务器标记
'host' => $_ENV['PHALPI_DB_HOST'], //数据库域名
'name' => $_ENV['PHALPI_DB_NAME'], //数据库名字
'user' => $_ENV['PHALPI_DB_USER'], //数据库用户名
'password' => $_ENV['PHALPI_DB_PASSWORD'], //数据库密码
'port' => $_ENV['PHALPI_DB_PORT'], //数据库端口
'charset' => $_ENV['PHALPI_DB_CHARSET'], //数据库字符集
),
),
);接着，在php-fpm.ini文件中，添加相应的配置：
env[PHALPI_DB_HOST]='localhost'
env[PHALPI_DB_NAME]='phalapi'
env[PHALPI_DB_USER]='root'
env[PHALPI_DB_PASSWORD]=''
env[PHALPI_DB_PORT]='3306'
env[PHALPI_DB_CHARSET]='UTF8'最后，重启php-fpm即可。
这样的好处莫过于可以支持项目代码的整包发布，而不需要在各个环境（开发环境、测试环境、回归环境、预发布环境、生产环境）来回修改切换配置，同时运维可以更好地保护服务器的账号和密码而不让开发知道。
而这样的不足则是，在对项目进行初次部署时，需要添加以上一系列的配置，而且后期维护也比较复杂麻烦，特别当机器多时。这时可以通过pupple/stacksalt这些运维工具进行自动化管理。但对于开发来说，依然会觉得有点烦锁。
(2)不同环境，不同入口
当服务器的账号和密码也是由开发来掌控时，则可以使用这种在代码层次控制的策略。
我们可以在Public下提供不同的入口，一如：
$ mkdir ./Public/myapi
$ myapi$ tree
.
├── index.php
└── test.php
我们有这样不同的入口，客户端在测试时，只需要将入口路径改成：/myapi/test.php?service=XXX.XXX，而在打包发布时只需要将入口路径改成：/myapi/?service=XXX.XXX 即可。也就是将test.php去掉。
而在服务端，仅需要在这些不同的入口文件，修改一下配置文件目录路径即可：
//$ vim ./Public/myapi/test.php
DI()->config = new PhalApi_Config_File(API_ROOT . '/ConfigTest');另外，也可以通过客户端在请求时带参数来作区分，如带上&env=test或者&env=prod。
(3)持续集成下的配置管理
但个人最为建议的还是在 持续集成 下作配置管理。
因为首先，持续集成中的发布应该是经常性的，且应该是自动化的。所以，既然有自动化的支持，我们也应该及早地将配置纳入其中管理。
配置文件不同只要是环境不同，而环境不同所影响的配置文件通常只有sys.php和dbs.php；为此，我们为测试环境和生产环境准备了各自的配置文件，而在发布时自动选择所需要的配置文件。一般地，我们建议生产环境的配置文件以 .prod 结尾。所以，这时我们的配置文件可能会是这样：
dogstar@ubuntu:Config$ tree
.
├── app.php
├── dbs.php
├── dbs.php.prod
├── sys.php
└── sys.php.prod多了生产环境的配置文件：dbs.php.prod和sys.php.prod。
再通过发布工具，我们就可以对不同环境的配置文件进行快速选择了。这里以phing为例，说明一下相关的配置和效果。
如下，在Phing的配置文件build.xml中，在生产环境发布过程中，我们将配置文件进行了替换。
//$ vim ./build.xml
<copy
file="./Config/dbs.php.prod"
tofile="./Config/dbs.php"
overwrite="true" />
<copy
file="./Config/sys.php.prod"
tofile="./Config/sys.php"
overwrite="true" />执行phing发布后，将会看到对应的这样提示：
[copy] Copying 1 file to /home/phapapi/Config
[copy] Copying 1 file to /home/phapapi/Config(4) 更灵活的配置覆盖管理方式
还有一种相当于.env形式的配置管理方式。即添加一个dbs.php.prod文件，但不需要复制全部的配置，只需要配置待覆盖的配置即可。例如，不同环境下，有不同的数据库配置。可以：
// $ vim ./Config/dbs.php.prod
<?php
return array(
/**
* DB数据库服务器集群
*/
'servers' => array(
'db_demo' => array( //服务器标记
'host' => '192.168.1.101', //数据库域名（仅数据库HOST、用户名、密码不同）
'user' => 'apps', //数据库用户名
'password' => '123456', //数据库密码
),
),
);然后，在dbs.php文件添加上面配置并覆盖原来的即可，如：
<?php
$rs = array(
// 原来的配置...
);
if (file_exists(dirname(__FILE__) . '/dbs.php.prod')) {
$rs = array_replace_recursive($rs, include(dirname(__FILE__) . '/dbs.php.prod')));
}
return $rs;这样，就可以通过新增一个dbs.php.prod文件，并且此文件是不纳入代码版本管理了，便可实现部署时的配置管理。
1.16.3 主从数据库的配置
通常一般而言，数据库支持分表分库配置，且只有一份，即：
./Config/dbs.php然后，我们这样指定数据库的配置：
DI()->notorm = function() {
$debug = !empty($_GET['__sql__']) ? true : false;
return new PhalApi_DB_NotORM(DI()->config->get('dbs'), $debug);
};如果需要从库时，可以参考./Config/dbs.php，创建一个从库的配置拷贝，即：
cp ./Config/dbs.php ./Config/dbs_slave.php然后，注册一个从库的notorm：
DI()->notormSlave = function() {
$debug = !empty($_GET['__sql__']) ? true : false;
return new PhalApi_DB_NotORM(DI()->config->get('dbs_slave'), $debug); //注意：配置不同
};最后使用此从库的服务DI()->notormSlave即可完成对从库的读取操作，用法同DI()->notorm，这里不再赘述。
1.16.4 扩展你的配置读取
虽然上面有不同的配置文件管理策略，但很多实际情况下，我们的配置需要可以随时更改、下发和调整。并且在海量访问，性能要求高的情况下快速读取配置。
这就要求我们的项目既可以方便维护即时修改，又需要能够快速同步一致更新下发和读取。这样就涉及到了配置更高层的管理： 统一集中式的配置管理，还是分布式的配置管理？ 文件存储，还是DB存储，还是MC缓存，还是进驻内存？
个人认为，性能最优的莫过于配置进驻内存并分布式存储。毕竟作为前端机的PHP内存这块还是相对充裕且可以利用的。但需要把这一条线打通，有点难度。
这里不过多地谈论配置更多的内容，但在PhalApi框架中，当你根据自己项目的需要实现了自己的配置读取方式后，再次简单的在入口文件重新注册即可。
1.16.5 使用Yaconf扩展快速读取配置
首先，非常感谢 @豹 同学的提议：使用Yaconf扩展快速读取配置。
虽然现在是冬天，有点冷（特别是在北京的同学），而且现在还是凌晨1点25分。但我们希望能继续将开源的热情继续下去。
以下是刚刚这几个小时努力的成果。
(1)前期准备：PHP7 的安装
具体可以参考：Linux环境PHP7.0安装
(2)前期准备：Yaconf扩展的安装
具体可以参考：laruence/yaconf
(3)使用
和正常的配置一样，简单如下：
DI()->config = new PhalApi_Config_Yaconf();
var_dump(DI()->config->get('foo')); //相当于var_dump(Yaconf::get("foo"));
var_dump(DI()->config->has('foo')); //相当于var_dump(Yaconf::has("foo"));以上，假设我们已经有了这样的配置文件：
$ vim ./test.ini
name="PhalApi"
version="1.3.1"需要注意的是，如果需要使用Yaconf扩展，需要PHP7的版本支持，但使用基本上和原来PhalApi的思路是完全一样的。
但还有所区别的是，配置文件的目录路径（当然也可以配置成和PhalApi的配置目录一致）、以及配置文件的格式。
Just have fun!
