54、企业级 PHP 应用部署与内容管理全解析

企业级 PHP 应用部署与内容管理全解析

1. rsync 实用工具简介

在现代项目部署中，常见需求是将服务器 B 上文件夹 A 的内容上传到服务器 D 上的文件夹 C。但考虑到现代项目源库的大小，为部署小改动而在互联网上传输数百兆数据效率低下。rsync 工具应运而生，它是 Linux/Mac OS X/UNIX 专用工具，虽有作者尝试开发 Windows 版本。rsync 能将本地服务器上指定文件夹的内容复制到远程服务器的指定文件夹，且只复制有更改的文件或文件部分，实现两文件夹同步，通常是单向同步，即从 A 到 B。

使用 rsync 的常见场景有：
- 将工作室预发布环境的内容部署到实时预发布环境。
- 将实时预发布环境（经批准后）的内容部署到实时生产环境。

rsync 甚至可用于同一服务器上的两个文件夹。服务器间复制时，它使用 SSH（紧急时用 RSH）协议，只需打开 TCP 端口 22 的防火墙规则。虽有 rsync 特定协议，但能用 SSH 时无需使用。

2. rsync 基本用法

通常将 rsync 作为 shell 脚本的一部分使用。例如，创建 deploy - studio - staging - to - live - staging 和 deploy - live - staging - to - live - production 脚本，调用 rsync 的语法如下：

rsync -avrz -e ssh /local/directory/* username@remotehost:/remote/directory

相关指令说明：
| 指令 | 说明 |
| ---- | ---- |
| -a | 实现存档模式，提供适合上述用法的预打包设置，传输时保留目录权限和符号链接。 |
| -v | 产生详细输出，显示实际选择复制的文件列表。 |
| -r | 递归复制。 |
| -z | 传输前压缩数据，同一服务器复制时可省略。 |
| -e ssh | 告诉 rsync 使用 SSH 传输文件，而非 RSH。 |
| /local/directory/ | 指定源目录， 表示复制该目录下所有文件。 |
| username@remotehost:/remote/directory | 指定远程目录，同一服务器复制时可省略 username@remotehost。 |

执行 rsync 命令时，可能会提示输入密码，即远程服务器上指定用户名的登录密码。

3. rsync 语法示例

• 工作室预发布环境到实时预发布环境 ：

rsync -avrz -e ssh /home/widgets/staging/* widgets@staging.widgets.com:/home/widgets/staging

• 同一服务器上实时预发布环境到实时生产环境 ：

rsync -avr /home/widgets/staging/* /home/widgets/live

此时省略协议指令，不启用压缩，因速度提升有限。
- 不同服务器上实时预发布环境到实时生产环境 ：

rsync -avrz -e ssh /home/widgets/staging/* widgets@live:/home/widgets/live

• 负载均衡多服务器部署 ：

rsync -avrz -e ssh /home/widgets/staging/* widgets@web01:/home/widgets/live
rsync -avrz -e ssh /home/widgets/staging/* widgets@web02:/home/widgets/live
rsync -avrz -e ssh /home/widgets/staging/* widgets@web03:/home/widgets/live

4. 用 rsync 保持服务器同步

若实时生产环境涉及多个 Web 服务器，rsync 还有重要作用。许多网站使用服务器可写的 /data 文件夹，存放不适合数据库（如 PostgreSQL 或 MySQL）的大型二进制文件和其他数据，如用户上传的文档。

多实时 Web 服务器设置中，新上传数据要让集群中所有 Web 服务器访问是个难题。一种方法是使用集中式文件服务器，通过网络文件系统（NFS）导出内容，但速度慢且有额外开销。另一种方法是频繁使用 rsync 在集群服务器间同步，新二进制文件上传后几分钟（甚至几秒）内传播到其他服务器。

不过，rsync 命令的键盘密码提示会影响定时任务调度。解决办法是使用无密码 SSH，连接前在客户端和服务器放置密钥文件。设置密钥驱动的 SSH 有挑战，可参考 此文档 。

使用此方法时，要注意应用需知晓上传后几分钟内二进制数据可能不可用。例如，若 cron 作业每五分钟运行一次，上传完成后五分钟内应抑制用户个人资料照片显示，显示“照片即将到来”消息，五分钟后正常显示。可在用户数据库记录中添加 time_photo_uploaded 属性并测量时间。若需即时访问上传照片，可实现系统：Web 服务器首次请求无照片时，立即与其他服务器进行 rsync，找到有照片的服务器后复制并显示给用户。同时，要确保上传数据文件名唯一，避免不同服务器显示不同版本。

5. 关于 FTP 的警示

FTP 是大家熟悉的文件传输协议，存在多年，许多廉价 ISP 将其作为向 Web 服务器传输文件的主要方式。但企业或专业级开发中，FTP 不可用。它存在安全漏洞，启用防火墙支持繁琐，且传输未加密，通过 FTP 传输的文件可能暴露给外界，增加未来入侵或攻击风险。建议使用 rsync，它使用安全复制协议（SCP）或安全 FTP（SFTP），基于 SSH 传输，更安全。

6. 内容管理概述

如今，客户常询问内容管理相关问题。过去，内容管理未被充分理解，如今随着博客、维基等工具出现，内容管理已成为主流。内容管理的教科书定义是“支持数字信息演化生命周期的一组流程和技术”。从更高视角看，内容管理涉及多方面：
- 人员 ：创建网络内容的人员可能集中或分散在全球，可能向单一部门汇报或作为志愿者贡献者松散关联，使用不同语言创作。
- 内容 ：内容形式多样，包括文本、图像、电影、富互联网应用、音频等，可按主题、文件类型、存储介质、地区、语言、受众群体等分类。
- 工作流规则 ：内容可能因多种因素应用不同工作流规则，如不同地区内容审核方式不同，编辑和发布者对不同贡献者信任程度不同，有些内容需多级审核，有些则信任初始贡献者。
- 发布后规则 ：发布后，某些类型内容可能需定期自动审核，确保相关性和准确性。

除内容管理系统（CMS）的严格功能要求外，还涉及运营和战略因素。编辑、作者和发布者需为特定受众发布内容，这需要进行受众分析。组织自身及其合作伙伴、供应商和投资者也是发布活动的利益相关者，发布内容应支持组织目标。此外，发布活动需遵守组织政策，确保内容安全备份，防止非法删除，维护服务器、数据库、软件和操作系统。

7. 内容管理简史

Web 内容管理故事始于 1995 年，InterLeaf 为在万维网上发布信息创建了 Cyberleaf，它能将文字处理文档转换为 HTML 并管理文档链接，是单源发布系统。同期，CNET 创建了内部 Web 发布系统 PRISM，使技术恐惧者也能轻松创建网页。1996 年，Ross Garber 和 Neil Webber 创立 Vignette，目标是使 Web 发布更简单和个性化。他们与 CNET 合作，将 PRISM 转化为 StoryServer 并于 1997 年发布，该产品优于当时的 CGI/Perl 构建动态网站方法。

此后，内容管理领域迅速发展，众多公司推出创新产品，涵盖工作流引擎、缓存技术、联合、个性化等方面。互联网泡沫破裂后，内容管理市场分裂为两大阵营：一端是企业级大型玩家，系统涉及大型服务器、大量备份和网络运营基础设施，需大量顾问和高额预算；另一端是新千年早期发展起来的开源应用，多基于 LAMP 堆栈，价格实惠或免费，客户可将资金用于定制前端、工作流和数据后端。

8. 常见开源 PHP 内容管理系统介绍

新千年早期发展起来的开源 PHP 内容管理系统各有特点，以下为你介绍一些常见的系统：
| 系统名称 | 特点 | 商业性质 |
| ---- | ---- | ---- |
| Mambo | 有商业版本，也有开源分支，为用户提供了一定的灵活性。 | 商业（有开源分支） |
| Joomla! | 是 Mambo 的分支，具有丰富的插件和模板，易于定制。 | 开源 |
| TYPO3 | 脱胎于 90 年代后期的系统，功能强大，适用于复杂的企业级应用。 | 开源 |

这些系统都以 LAMP（Linux, Apache, MySQL, PHP）堆栈为基础，与之前的企业级系统形成鲜明对比，它们价格亲民甚至免费，用户可以将资金投入到前端定制、工作流优化和数据后端处理上。

9. 内容管理系统的选择与考量

在为自己的应用推荐或指定内容管理系统（CMS）时，需要综合多方面因素进行考量，以下是一个简单的决策流程图：

graph LR
    A[明确需求] --> B{预算限制}
    B -- 预算充足 --> C{功能复杂度}
    B -- 预算有限 --> D{开源优先}
    C -- 高复杂度 --> E[选择企业级系统]
    C -- 低复杂度 --> F[选择开源或轻量级商业系统]
    D -- 是 --> F
    D -- 否 --> G[选择商业系统]
    F --> H[考虑易用性和社区支持]
    E --> I[评估技术团队能力]
    G --> J[对比不同商业系统特性]

在这个流程中，首先要明确自己的需求，这是选择的基础。如果预算充足，需要进一步考虑功能复杂度，对于高复杂度的需求，企业级系统可能更合适；而对于低复杂度需求，开源或轻量级商业系统就可以满足。如果预算有限，优先考虑开源系统，但如果对开源系统不满意，也可以选择商业系统。在初步筛选后，对于开源或轻量级商业系统，要考虑其易用性和社区支持；对于企业级系统，要评估技术团队的能力是否能够驾驭；对于商业系统，则需要对比不同系统的特性。

10. 内容管理系统的开发需求清单

如果你想自己编写内容管理系统，以下是一份开发者的需求清单：
- 功能需求
- 支持多种内容类型的创建、编辑和存储，如文本、图像、音频、视频等。
- 提供灵活的内容分类和标签功能，方便内容的组织和检索。
- 实现内容的版本控制，以便追溯和恢复历史版本。
- 集成工作流引擎，支持内容的审核、发布和归档流程。
- 性能需求
- 具备高并发处理能力，能够应对大量用户的访问。
- 优化数据库查询和存储，提高内容检索和加载速度。
- 支持分布式存储和缓存技术，减轻服务器压力。
- 安全需求
- 对用户进行身份验证和授权，确保只有授权用户可以访问和操作内容。
- 对内容进行加密存储，防止数据泄露。
- 定期进行安全漏洞扫描和修复，保障系统的安全性。
- 用户体验需求
- 提供简洁易用的用户界面，降低用户操作难度。
- 支持多语言和多主题，满足不同用户的需求。
- 提供良好的响应式设计，适应不同设备的屏幕尺寸。

11. 内容管理的战略意义总结

内容管理不仅仅是构建或安装一个内容管理系统（CMS），它涉及到组织的战略、运营和技术等多个层面。从战略角度看，内容管理有助于组织跟上市场信息发布的节奏，使发布的内容支持组织的目标，避免内容策略与业务策略冲突。从运营角度看，要确保内容的安全备份、服务器和数据库的维护以及软件和操作系统的更新。

一个 CMS 是对组织快速、轻松、有效地发布和维护信息需求的技术回应。它的核心价值在于帮助组织在信息发布方面保持竞争力，满足市场需求。在选择和使用内容管理系统时，要综合考虑各种因素，结合组织的实际情况做出最合适的决策。无论是选择现有的开源或商业系统，还是自己开发，都要以实现内容管理的战略目标为导向。