这是很值得一看的 PDF：Flickr and PHP。文档中对于 Flickr 的架构进行了剖析，下边列出一些重点，以及我们（公司）当前相应的一些应用与个人观点：

• 使用 PHP 实现公共 API 接口，XML-RPC、SOAP 等；（目前我们对于 XML-RPC 运用得比较广泛）
• 使用 Smarty 模板引擎；（我已经开始厌烦 Smarty 的语法了）
• 使用 ImageMagick 处理图片；（这东东真的很好用）
• 使用 MySQL InnoDB，应用 MySQL replication 功能，实现 SELECT 和 INSERT/UPDATE/DELETE 操作分离，分别操作不同的 MySQL 数据库/服务，因为 SELECT 操作远多于 I/U/D 的操作，而 I/U/D 又会阻塞 SELECT 操作；（我们曾经也提出过这样的方案，但需要更多硬件的支持）
• 使用 MySQL MyISAM 的全文检索功能，将 InnoDB 在数据库复制过程中转换成 MyISAM，并使用单独的 MySQL 数据库/服务支持全文检索；（为什么不用 Lucene 呢？）
• 邮件使用 Postfix，由其在接收到邮件之后，将邮件转给 PHP 程序处理；（我们的 WEBMAIL 也是这样做的）
• FTP 服务端使用 Java，接收到上传文件之后交由 PHP 程序处理；（我们用的是 pureftpd 及客户端 FTP 控件，由控件在上传文件完成之后通知某个 URL 的 PHP 程序接棒处理。pureftpd 的方便之处在于可以使用 MySQL 数据库对用户、文件数、空间进行管理）

Flickr 的架构使用 PHP 达到了 90% 左右。目前单纯使用 PHP 实现企业级应用似乎很困难，比如著名的 Ning 也不是纯 PHP 的，有相当一部分的 Java 在支持着，而 Yahoo! 的 PHP 应用则是夹杂了很多 C/C++。有很多方面制约着 PHP 在这方面的发展，比如 PHP 不支持多线程（而这个 Java 等很在行），不适合作为后台守护程序（因为其存在有不少内存泄漏问题，我们曾经为此非常苦恼），对 XML/XPath 的支持不够好，对 Unicode 的支持不够好等等。虽然很多方面 PHP 的后续版本正在改进，但对于一个复杂的企业级应用，也许综合多种语言、技术才是最优方案。

PDF文件