如何正确发布PHP代码

　　几乎每一个 PHP 程序员都发布过代码，可能是通过 ftp 或者 rsync 同步的，也可能是通过 svn 或者 git 更新的。一个活跃的项目可能每天都要发布若干次代码，但是现实却是很少有人注意其中的细节，实际上这里面有好多坑，很可能你就在坑中却浑然不知。下面是小编为大家带来的关于如何正确发布PHP代码的知识，欢迎阅读。

　　如何正确发布PHP代码

　　一个正确实现的发布系统至少应该支持原子发布。如果说每一个版本都表示一个独立的状态的话，那么在发布期间，任何一次请求只能在单一状态下被执行。如此称之为支持原子发布；反之如果在发布期间，一次请求跨越不同的状态，那么就不能称之为原子发布。我们不妨举个例子来说明一下：假设一次请求需要 include 两个 PHP 文件，分别是 a.php 和 b.php，当 include a.php 完成后，发布代码，接着 include b.php，如果处理不当的话，那么就可能会导致旧版本的 a.php 和新版本的 b.php 同时存在于同一个请求之中，换句话说就是没有实现原子发布。

　　开源世界里有很多不错的发布代码工具，比如 ruby 社区的 capistrano，其流程大致就是发布代码到一个全新的目录，然后再软链接到真正的发布目录。

　　├── current -> releases/v1

　　└── releases

　　├── v1

　　│ ├── foo.php

　　│ └── bar.php

　　└── v2

　　├── foo.php

　　└── bar.php

　　不过鉴于 PHP 本身的特殊性，如果只是简单套用上面的流程，那么将很难实现真正的原子发布。要理清个中缘由，还需要了解一下 PHP 中的两个 Cache 的概念：

　　opcode cache

　　realpath cache

　　先聊聊 opcode cache，基本就是 apc 或者 zend opcode，关于它的作用，大家都已经很熟悉，不必多言，需要注意的是 apc 的 bug 很多，比如开启了 apc.enable_cli 配置后就会有很多灵异问题，所以说 opcode cache 还是尽可能使用 zend opcache 吧，如果需要缓存数据，可以用 apcu。此外 apc 和 zend opcode 对缓存键的选择有所差异：apc 选择的.是文件的 inode，zend opcode 选择的是文件的 path。

　　再聊聊 realpath cache，它的作用是缓冲获取文件信息的 IO 操作，大多数时候它对我们而言是透明的，以至于很多人都不知道它的存在，需要注意的是 realpath cache 是进程级别的，也就是说，每一个 php-fpm 进程都有自己独立的 realpath cache。

　　假设在发布代码期间，opcode cache 或者 realpath cache 里的数据出现过期，那么就会出现一部分缓存是旧文件，一部分缓存是新文件的非原子发布的情况，为了避免出现这种情况，我们应该保证缓存过期时间足够长，最好是除非我们手动刷新，否则永远不过期，对应到配置上就是：关闭 apc.stat、opcache.validate_timestamps 配置，设置足够大的 realpath_cache_size、realpath_cache_ttl 配置，必要的监控总是有好处的。

　　相关的技术细节特别琐碎，建议大家仔细阅读如下资料：

　　realpath_cache

　　PHP’s OPCache extension review

　　Atomic deploys at Etsy

　　Cache invalidation for scripts in symlinked folders

　　在采用软链接发布代码的时候，通常遇到的第一个问题多半是新代码不生效！即便调用了 apc_clear_cache 或者 opcache_reset 方法也无效，重启 php-fpm 自然是能够解决问题，不过对脚本语言来说重启太重了！难道除了重启就没有别的办法了么？

　　BTW：如果需要手动重置 opcode cache，需要注意的是因为它是基于 SAPI 的概念，所以不能直接在命令行下调用 apc_clear_cache 或者 opcache_reset 方法来重置缓存，当然办法总是有的，那就是使用 CacheTool 在命令行下模拟 fastcgi 请求。

　　事实上之所以会出现这样的问题，主要是因为 opcode cache 是通过 realpath cache 获取文件信息，即便软链接已经指向了新位置，但是如果 realpath cache 里还保存着旧数据的话，opcode cache 依然无法知道新代码的存在，缺省情况下，realpath_cache_ttl 缓存有效期是两分钟，这意味着发布代码后，可能要两分钟才能生效。为了让发布尽快生效，需要以进程为单位清除 realpath cache：

　　<?php

　　$key = 'php.pid_' . getmypid();

　　if (($rev = apc_fetch($key)) != DEPLOY_VERSION) {

　　if($rev < DEPLOY_VERSION) {

　　apc_store($key, DEPLOY_VERSION);

　　}

　　clearstatcache(true);

　　}

　　如此在 apc 环境下基本就能工作了，但是在 zend opcode 环境下还可能有问题。因为在缺省情况下 opcache.revalidate_path 是关闭的，此时会缓存符号链接的值，这会导致即便软链接指向修改了，也永远无法生效，所以在使用 zend opcode 的时候，如果使用了软链接，视情况可能需要把 opcache.revalidate_path 激活。

　　分析到这里，我们不妨反思一下：在 PHP 中原子发布之所以是一个棘手的问题，归根结底是因为软链接和缓存之间的的矛盾。不管是 opcode cache 还是 realpath cache，都是 PHP 固有的缓存特性，基于客观需要无法绕开，如此说来是否有办法绕开软链接，使其成为马奇诺防线呢？答案是 nginx 的 $realpath_root：

　　fastcgi_param SCRIPT_FILENAME $realpath_root $fastcgi_script_name;

　　fastcgi_param DOCUMENT_ROOT $realpath_root;

　　有了 $realpath_root，即便 DOCUMENT_ROOT 目录中含有软链接，nginx 也会把软链接指向的真正的路径发给 PHP，也就是说，对 PHP 而言，软链接已经不存在了！不过作为代价，每一次请求，nginx 都要通过相对昂贵的 IO 操作获取 $realpath_root 的值，通过 strace 命令我们能监控这一过程，下图从 current 到 foo 的过程：

　　realpath

　　在本例中，压测发现使用 $realpath_root 后，性能下降了大约 5% 左右，不过明眼人一下就能发现，虽然 $realpath_root 导致了 lstat 和 readlink 操作，但是 lstat 操作的次数是和目录深度成正比的，也就是说目录越深，执行的 lstat 次数越多，性能下降也就越大。如果能够降低发布目录的深度，那么可以预计性能下降能够控制在 1% 左右。

　　结尾介绍一下 Deployer，它是 PHP 中做得比较好的工具，有很多特色，比如支持并行发布，具体演示如下图，左边是串行，右边是并行，使用「vvv」能得到更详细信息：

　　deploy

　　不过 Deployer 在原子发布上有一点瑕疵，具体见 deploy:release 代码：

　　<?php

　　run("cd {{deploy_path}} && if [ -h release ]; then rm release; fi");

　　run("ln -s $releasePath {{deploy_path}}/release");

　　也就是说，在切换软链接的时候，它是先删除再创建，是一个两步操作，理论上如果有请求在这两步中间进入的话，那么将会出现找不到文件的错误。

　　问题到这里，大部分人会觉得使用「ln -sfn」就好了，实际上也是错误的：

　　shell> strace ln -sfn releases/foo current

　　symlink("releases/foo", "current") = -1 EEXIST (File exists)

　　unlink("current") = 0

　　symlink("releases/foo", "current") = 0